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. 

Service Class Automation

Just to clarify the term, "Service Class" (or Class of Service) usually assigns a name to the delivery of specific services. A good example is the classic Bronze / Silver / Gold terms, where Bronze might provide basic monitoring and AV while Gold provides advanced monitoring, proactive maintenance, and comprehensive endpoint security services. This can related to several services within an MSP practice, including monitoring, software, maintenance, patching, and security.

The RMM Suite employs a basic Service Class of Unmanaged and Managed, which is used broadly to apply or block automation. 

Unmanaged - This can be a "break/fix" or "time and materials" customer with no automation. RMM Suite customers also use this mode to onboard new clients. Since an unmanaged customer receives no automation, it allows a period of time after deploying agents to perform discovery actions. This can lead to preparing custom configurations, setting up software licenses for automated deployments, and identifying any special monitoring requirements. Once all customer preparation is completed, a client can be switched to Managed. This is defined using either a Customer Custom Field or - in VSA - a Machine Group root name.

Managed - This represents a generic state where ALL automated services can be applied. The automation policies specifically look for the "unmanaged" status, treating all other status types as "managed". This allows a generic classification of "managed" as well as specific sub-classifications or Service Classes. The service classes can also be used to drive client billing.

Service Classes - These are codes - whether colors, metals, animals, or simply an alpha-numeric ID - that define a specific set of services. These codes can be distinct or cumulative - that's completely up to the MSP. Cumulative codes take a bit more planning and configuration effort, but can simplify certain aspects of the automation.

Distinct Code Mapping

Distinct codes will map a set of specific components and services to a single code. A system filter identifies the code and applies the appropriate services. Note that the same services can be associated with multiple Service Class codes.

Iron - Basic AV, Patching

Steel - Basic AV, Antimalware, Patching, Application Updating, Basic Monitoring

Titanium - Advanced AV, Endpoint Security, Antimalware, Patching, Application Updating, Basic Monitoring, Advanced Monitoring

There are three automation policies and three filters. The filter checks for the Service Level code and applies the automation policy. The policy applies the products and services that are part of the Service Class. You will see that two policies have Basic AV, Antimalware, and Application Updating, three have Patching, and two have products unique to that class, This is a simple mapping of code to services and works well when there are a small set of classes and products.

Cumulative Code Mapping

This method creates a filter and automation policy for each distinct product or service instead of the service class. The filter applies a specific product or service when it matches one or more Service Class codes. This is how it works:

Basic AV - Filter triggers at Iron OR Steel levels

Advanced AV - Filter triggers at Titanium level

Antimalware - Filter triggers at Steel OR Titanium levels

Patching - Filter triggers at Iron OR Steel OR Titanium levels

Basic Monitoring - Filter triggers at Steel OR Titanium levels

Advanced Monitoring - Filter triggers at Titanium level

While this is certainly more complex and requires distinct filters and automation policies for each service, it provides greater flexibility when there are additional Service Classes. Consider adding a new "Tin" service class that only provides patching, and an "Aluminum" level with Patching and Application Updating. By simply updating the filter associated with the products to trigger on these new service classes, the automation applies without the need to create both new filters AND automation policies. 

How the RMM Suite uses Service Class Mapping

Each day, when the Daily Audit application runs, it determines the Service Class code assigned to the customer. This starts by checking for a Customer Custom Field called CCOS. The value - if defined - is mapped to the "SC:id" tag and written to the System Roles Agent Custom Field, along with any other TAGs based on the applications and services found. The TAGs can be used to drive views to apply policies, which is useful for applying the monitors associated with these Service Classes. The TAG can also be used directly by the Daily Maintenance tool to install application components, either by local script or RMM script.

A second advantage of this method is the Service Class identity is added to a machine-specific field. Some RMMs do not expose the Customer Custom Fields to agent scripting and this circumvents that deficiency.

Using a Standard Configuration

This concept starts by defining a set of configuration settings and software that needs to be deployed within your support stack. This should include settings and software that you deploy to most or all customers, then settings and software deployed to specific customers. The latter is usually LOB applications, as the RMM Suite install scripts can leverage Cloud Script Variables (CSVs) to both control the deployment globally while delivering customer-specific content.

As your product stack changes - either by adding or replacing products - your Standard Configuration changes. This has been a difficult process for many as configurations may need to change and software uninstalled before installing a new set of products. This is where the RMM Suite OBA tool can help.

Deploying the Standard Configuration

The OBA tool runs when an agent first checks in to deploy software and configure the endpoint to meet the Standard Configuration requirements. See this blog post for full information on using the OBA Tool and the Standard Configuration. 

Dealing with Change

Change is inevitable, but it should not be difficult! A typical change to a Standard Configuration is using a different product, such as Antivirus software. Let's assume your Standard Configuration utilized Iron-Man AV, but now you are switching to the more powerful Titanium-Man AV product. You need to remove the old product and then install the new one. This requires just 2 scripts and 3 changes to your OBA config file:

Script: Uninstall Iron-Man AV - Create an RMM script to uninstall the Iron-Man AV product, suppressing any reboots.

Script: Install Titanium-Man AV - Create an RMM script to install the new Titanium-Man AV product, suppressing any reboots

Change the OBA configuration file:

• Disable or Remove the definition that installed the IronMan AV product
• Add a definition to run the Uninstall Iron-Man AV script
• Add a definition to run the Install Titanium-Man AV script

Once these changes are in your OBA configuration file, the next daily cycle will discover that these two tasks have never been run and will run them on all endpoints (based on the Task Category where these are defined, of course). The next time the endpoint is online and runs the Daily Tasks, these changes to your Standard Configuration will be processed and the endpoint will be compliant with your new standards.

Summary

Despite the "Onboarding Automation" name, the capabilities of the OBA tool extend to helping you maintain a "Standard Configuration" without complex scripting or other RMM automation tools. The OBA tool also works hand in hand with the Daily Maintenance tool that can be used to deploy and update components on the endpoint, especially when using Customer Class of Service (CCOS) tags. Daily Maintenance could be used to deploy and maintain either Iron-Man AV or Titanium-Man AV based on the CCOS tag being "Iron" or "titanium" (or any other level-identification term). 

 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!

The phenomena, usually, occurs after several months of debating whether or not to let a problem employee go. The shocking discovery, however, seems to be the same no matter what terms the former employee leaves under. Of course, compounding the entire issue is the fact that as owners or managers we no longer believe that we remember how to do many of the tasks performed by others.

As MSPs we are constantly discussing the “pro-active” measures we take on behalf of our clients. Yet somehow, we don’t think pro-actively when it comes to our own businesses. We work tirelessly to build a team of people that handle every aspect of our businesses. We remove ourselves from the day-to-day operations of the business and celebrate the fact that we did so as if it is our lifelong goal.

Perhaps, after we finish celebrating, we should apply that pro-active mentality to the health of our businesses. When’s the last time you jumped in and just worked a ticket? Spent half a day as a Service Coordinator? Handled the Approve & Post process? Performed a Strategic Business Review? Not only should you and your leadership team jump in every once in a while, you should do so in areas that are not necessarily in your wheelhouse.

Actually, pull the documentation and follow it to the end. Analyze everything about the environment surrounding the task and take note of where it can be improved. Take the time to look at how previous tickets for the client were handled, how the billing was done the previous month, what was discussed at the last SBR. In other words, pro-actively look for where the processes are not being followed or can be improved. Look for areas where your staff is less than perfect. You don’t have to necessarily take actions on any of your findings. Just use the information to avoid surprises down the road.

Steve Alexander / MSP-IGNITE

Steve Alexander has over 30 years of experience running multiple IT Service Providers and MSPs. As the owner of MSP-Ignite he facilitates industry leading peer groups with a unique approach designed to make every member feel like they are being guided towards their own goals by a private consultant.

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!

The first thing to recognize is that the monitor for Agent Check-In has nothing to do with whether a server is functioning. The agent is simply a service-based application on the server. It's job is to communicate with the VSA on a regular schedule and determine if it should either perform tasks or deliver information. This is considered a low-priority service, and - by design - the agent will relinquish resources when the server is under stressful load conditions. This could prevent the agent software from checking in with VSA for several minutes. When this triggers an alarm, it clearly isn't because the server has crashed or become otherwise unavailable. It's just busy.Servers starting to run backups shortly after midnight would trigger a rash of agent offline alerts, waking up the on-call team member, who would find everything working just fine.

So - how can this be improved? The first step is to set the check in time to a longer period to identify when the agent software has a problem. Our default is one hour.

Next, use an Out of Band monitor to check server health. Kaseya Network Monitor is built into VSA and can handle the job nicely. Don't use ping, because a smart NIC will reply even if the O/S has crashed. We check for the Server service, which typically must be running for the server to function, but more importantly, to get a response, the Operating System has to be functional. We set the time on this monitor long enough for the server to reboot without triggering an alarm, but short enough so that a failure will be detected and reported in a timely manner. The default alarm time we use is 15 minutes for most servers, and 7 minutes for critical systems.

We then add a set of monitors that report when the server has rebooted during business hours or booted into system recovery modes. These are Smart Monitors that run at startup and check for these specific conditions. Alarms for business hours reboots fire immediately, while recovery mode detection delays a brief period so an engineer can boot, perform a quick recovery operation, and reboot again.

Finally, we configure the agent to generate alarms for certain crash conditions. This might result in two alarms for the same event - one for the work-day reboot and one for the reason why.

With this method, our customers get better information, faster and more appropriate alerting, and virtually zero false alarms for server-down conditions.

When you go to the shopping mall, you lock your car, right?

If you have your tech kit with you, you lock it in the trunk, right?

When you leave for work in the morning, you lock the front door of your house, right?

You tell your kids not to take candy from strangers, right?

These are all forms of "best practices" that we follow without thinking, so why do we still open port 3389 for RDP? The common answer is that the client can't afford to implement an RDP gateway or licenses for VPN access. Then there are the outdated and unpatched systems. These are often needed to provide access to archival data, but are still on the network. Take them off the network or put them in a separate network with restricted access.

The questions you need to ask are:

• Can your customer's business survive if they lost every bit of data they had?
• Could they pay the "ransom" if their data was encrypted?
• What would be the impact to your business when your client suffers a loss because you didn't observe (or enforce) good practices.

We have Standards and Practices documents for many aspects of our MSP practice. These ensure that the work we do is consistent and follows reasonable and secure methods. Our "SAP" documents cover things like building web servers, creating a network time infrastructure, server disk partitioning, securing admin accounts, network segmentation, printer management, and building virtualization platforms (with specifics for VMware and Hyper-V). These range from as few as three pages to two dozen or more, depending on the topic and number of variations.

These are guidelines, not rules, that establish the specific configuration and "build" documents that the engineers follow. This takes some effort, but standards breed consistency and that provides a level of control over the environments. When you control an environment, you increase the overall reliability, which reduces your work and improves customer satisfaction.

The entire MSP Builder solution stack is built on standards and consistency. This allows us to develop automation that works well because it leverages the standards in our foundational products. This also helps with security - everything is designed and documented, not merely "implemented". If a risk is discovered, it's easy to identify the scope and remediate.

So - start small.. create some basic operational standards and follow them! Get buy-in from your engineers, because your business is only as good as your staff. Not sure where to start? We've posted our Standards Documents in the document library on the downloads page, available for free to registered users. Use Google and see what others are doing and adapt to your environment. Don't delay.