The LAUSER Account

Back in 2019, a customer related an experience of when a VIP user at a major customer was in an airport lounge. The user needed to print their presentation and needed admin access to install the print driver. The WiFi was limited to http protocol access, which prevented the MSP from using their RMM to provide support. They had no choice but to provide the user with their internal use password. This required changing the password throughout that customer environment. We suggested that a commonly named account ("lauser") could be created and our automation could maintain and update the credentials on a weekly basis. We rolled that process into ITP and began deploying this account for our customers soon after.

A few years later, MSPs are looking to improve security and decide to use the LAUSER account for their local access. This led to an additional improvement in this component, allowing multiple accounts to be created using this process.

One of the unique security features of this process is that the password is generated based on using the date, time, and hostname, along with other logic, to seed the password generation logic. This ensures that the password is machine-specific and impossible to re-synthesize.

The RAUSER & CAUSER Accounts

The RMM Suite has long supported the use of per-client accounts for the MSP (RAUSER) and the customer (CAUSER), first via Managed Variables in Kaseya VSA and now via self-ciphering Cloud Script Variables on all RMM platforms. These accounts offer the flexibility of selecting the actual login ID, display name, and password. These credentials apply to groups of agents, whether an entire customer organization or specific location or department.

RMM Suite Account Management Tools

The RMM Suite continues to support multiple methods of local account management.

• If the RAUSER (or CAUSER) Cloud Script Variable (CSV) is defined (both UserID and Password), the account will be created, added to the local administrators group, and the defined password will be set on the account. This happens automatically the first time that an agent checks in. These accounts can be updated at any time by updating the account password stored in the CSV and then executing the appropriate WIN-Local Account script on the RMM platform, targeting the endpoints where the account should be updated.
• The LAUSER technology has been enhanced and migrated into our Daily Maintenance tool. Simply create a Weekly or Monthly task to run the LAUSER command. This will generate a long, complex password; create the account and add it to the Administrators group if necessary; then set the password. The password will be ciphered and written to the system registry, where it can be collected by the Daily Audit tool, deciphered, and pushed into the RMM or your documentation engine such as Hudu or IT Glue. You can define multiple tasks in Maintenance with the LAUSER command to create any number of local admin accounts with unique credentials. 
  • If no argument is defined, the account name "lauser" is targeted. This maintains the process we implemented several years earlier and allows this account to be given to the user as necessary. It may be appropriate to update the frequency of this account change.
  • If an argument is provided, it will be used as the account name. This argument should be a single word without spaces, following the usual guidelines for user account IDs. 

 In our typical VSA implementation, we create four distinct access levels, and several sub-types for MSP employees, plus three roles for customer access. No user has Master role rights in our deployment configuration. These roles should have a “NOC” or “MSP” prefix to designate them as internal roles.

Level 0 – Support A role designed for support staff to access VSA for running reports, getting agent counts, or checking use and available licensing. No access to automation is available, but these users can view agents and have virtually unlimited access to the reporting functions.

 Level 1 – Technician This role, which we name “NOC-1-Tech”, grants the ability to perform basic agent administration, view audit and other configuration settings, and access remote control features. This provides the ability to perform about 80% of what a technician would do on a daily basis for end-user support.

Level 2 – Administrator Named “NOC-2-Admin” in our system, it grants additional capabilities to run procedures, deploy AV and AM, and perform most agent configurations. Neither of the above roles permit changing the configuration of VSA-wide settings.

Level 5 – Specialist These roles grant VSA administration rights to specific features, distributing the administration tasks among multiple users. In our practice, we use the following specialist types:

• Security – provides the ability to perform all Auth Anvil configuration and management tasks.
• AV-Malware – grants access to administer the Antivirus and Malware components, including definition of profiles, policies, and assigning them to customers.
• Updating – allows administration of all Patch Management and Software Management components. It may also allow access to other application updating components.
• Backup – Allows configuration of all VSA settings related to backup operations.
• Manager – grants a combination of roles, usually assigned to the Dispatch, helpdesk or Technical Manager(s).

Implementing these security roles will allow for better security and organization within your VSA infrastructure. To learn more, schedule a demo for MSP Builder’s RMM Suite!

Since you are already in a protected environment (you lock your doors and have a firewall and other logical and physical security – right?), you don’t need to require MFA. Most MFA solutions provide one or more methods of “whitelisting”. Which method you choose will make the difference between being secure and not…

User Whitelisting

User whitelisting is used for application accounts that would not be accessed externally, or support accounts that need to be used by external support teams. You would never whitelist your employees! Unfortunately, we see this configuration all too often. When we point it out, the response is typically “yes, but we trust our team!”

Sure – you can trust your employee, but you can’t trust their credentials! That’s the distinction that MFA makes. If an employee’s credentials are compromised, any bad actor can try to log in. If their account is whitelisted, there would be no Multi-Factor authentication and access would be granted!

Network Whitelisting

Network whitelisting identifies the internal network range(s) that you trust – typically the office network public addresses. In most situations, this would be the public IP address assigned to your external firewall (or firewalls if you have redundant Internet connections). This is the preferred way to allow your techs to work without MFA when in the office, but require it when they are at home, customer sites, or otherwise outside of the office.

MSP Builder Tools

Many of the MSP Builder tools utilize the VSA APIs to perform their tasks. While these tools use the API to authenticate over an SSL connection, there are some processes that we follow to improve the security of these tools. As each tool runs, it requests an authorization token to do its work by authenticating to VSA. The tasks that the tools perform take anywhere from a few milliseconds to about 3 seconds to complete. Once the task completes, the tool closes the session, invalidating the authorization token.

Another level of security that we use is MSP Builder License Authorization. All tools that utilize the APIs must first authenticate to the MSP Builder licensing server. This authorization is such that it is extremely difficult (if not impossible) to circumvent, requiring multiple data parts to complete a license validation. In a sense, this is a form of MFA for the tools that utilize the Kaseya APIs. Our API account does not require the password to be distributed to the systems that use it, and is designed to be changed on a 24-hour cycle, increasing the difficulty of a brute-force attack.

Summary

Multi-Factor Authentication is an excellent method to improve the security and integrity of your environment, but it requires careful and correct configuration. Incorrect settings will negate the security you’re trying to deploy, so take your time, double and triple-check your configuration, and use whitelisting options properly!