Simple Yet Powerful: How Granular Authorization Keeps Your Network Secure

March 31, 2021
Daniel Verastiqui

Written by Daniel Verastiqui

Daniel Verastiqui is the Director of Client Services and Corporate Communications at Uplogix, Inc.

If the movie Wargames taught us anything, it’s that you shouldn’t leave your computer systems so wide open that even Ferris Bueller can just walk right in. Nowhere is that more important than in a remote management platform that is directly connected to your core routers and switches. Remote access and automation come at a cost, but that’s no reason they can’t be as secure as any other system in your network. In this post, we’ll look at how Uplogix respects the privileged access you give it with a robust AAA model that includes what we call Granular Authorization.

Dial W for War

Just like traditional terminal servers before it, the Uplogix Local Manager provides users with direct console access to network equipment through both in-band and out-of-band channels. If a user can open a terminal session on one of the managed ports, they will essentially have the same access as if they were physically at the site and plugged into the network gear with a laptop and a console cable. With the Local Manager sitting on the network, we want to make sure we don’t give this direct console access to just anyone.

Uplogix uses a standard AAA model to define who can access a Local Manager, what they can do once they’re in, and how their actions should be logged. We break out the AAA model in the following way:

  • Authentication – local or integrated with existing TACACS, RADIUS, or LDAP environments
  • Authorization – role-based, defined locally or through third-party AAA ACL names
  • Auditing – local always, offload to third-party Accounting servers available

Authentication and Auditing are pretty straightforward—usernames and passwords are checked, and every action is logged. Where the Local Manager shines is in the definition of role-based Granular Authorization that allows you to specify what a user can do down to a single command. Not only that, you can also specify where that command can be run.

Let’s take a closer look.

Who, What, and Where

If you were to create a user in your Uplogix deployment, give them a username and password, and then immediately try to log in, it would fail. Although the system can authenticate the user, it cannot yet authorize them to do anything. Without authorization (even the authorization to simply log in), the login attempt is denied.

Consider a set of statements like: User X has role Y on resource Z.

These statements define authorization throughout the entire Uplogix deployment.

It breaks down like this:

  • User – can be a group or individual user
  • Role – a list of allowed and denied commands
  • Resource – system, port, modem, all, or server

When configuring your Uplogix deployment to match your security policy, most of the work will be done in the creation and customization of roles.

A Role for Everyone

By default, Local Managers ship with just two roles: admin and guest. The admin role includes almost every privilege and is intended for initial setup and/or super users. The guest role allows limited, read-only access to the system. Most customers end up creating a couple custom roles to meet their needs.

As shown in the screenshot above, a role is simply a list of permissions that either allow or deny access to a command. Most of the permissions map to specific commands (e.g., config answer), but others like login and use system auth don’t have associated commands. Every command begins with a blanket deny; a user must be assigned an allow permission to run the command.

Roles define which commands can be run. Multiple roles can be combined and evaluated together. For example, if a user is assigned the admin role and a role that denies access to the config answer command, the user will have access to every command in the admin role except config answer, because the deny statement in the second role takes precedence.

If you are new to Uplogix, you may not know enough about every command to build a new role from scratch. One option would be to assign everyone the admin role and a second role that denies administrative actions like config user or config system management.

Sound complicated? Don’t worry. An Uplogix Deployment Specialist will work with you to understand your security policy and help you configure your deployment to match it. We help every step of the way.

Once your roles are created, you can assign them to users on resources.

We Have the Resources

In the Uplogix world, giving a user a role on a resource is called Assigning Privileges. Privileges can be assigned to the Uplogix Control Center server, Inventory Groups, and individual Local Managers. We generally assign users or groups a role on the Control Center server and a role on the root Inventory Group so that all Local Managers can inherit the privileges.

Assigning privileges is as easy as accessing the Privileges section in an Inventory Group or single Local Manager. The menu shown above allows you to choose a Resource, a User/Group, and a Role.

At Inventory Group levels, options for Resource include all, modem, powercontrol, and system. When assigning privileges on a single Local Manager, each of the ports are listed so that some users can be assigned to ports 1/1 – 1/8 while others are assigned to 2/1 – 2/8. Additionally, ports can be labeled throughout the deployment, and those labels will appear in the Resource dropdown, allowing you to assign privileges to all ports labeled with, for example, firewall, in the entire deployment.

Putting it All Together

No two deployments are the same, and we’ve seen customers with just three users give everyone the admin role on every resource, and we’ve seen customers with thousands of users create multiple groups, multiple labels, and give end-users access to their routers or switches and nothing else. Granular Authorization allows you to get as detailed as necessary but isn’t so complicated that you can’t get up and running quickly.

By customizing roles and assigning privileges, we can do a lot of cool things like:

  • Limit users to port-passthrough for a managed device (e.g., SSH to IP on port and get to router)
  • Use labels to give a group access to all firewalls or switches throughout the deployment
  • Limit administrative access by creating roles that deny those tasks and use them in conjunction with the admin role
  • Give a user access to just one port
  • Give a user access to the system and no ports
  • Give read-only access to resources
  • Assign privileges to multiple User groups and have user inherit those privileges when assigned to that User group

To summarize: when you add a user, you will be able to define which commands they can and cannot access on every system, modem, and port resource in your entire deployment.

By limiting users to only the commands they need to perform their work, we add an extra layer of protection in the event their account credentials are compromised. Role-based Granular Authorization would limit the exposure to only the resources for which they have privileges.

Essentially, Matthew Broderick isn’t doing anything on your Local Manager that you, as the administrator, haven’t given him permission to do. And really, isn't that why computer security was invented?

Further Reading: Uplogix Privileges

The Larger, More Secure Picture

Of course, Authorization is only one part of how Uplogix keeps your managed devices safe. In the coming weeks, we’ll explore more about how we handle security and review best practices for keeping your deployment as secure as possible.

As always, if you have any questions or would like to talk more about Granular Authorization, drop us a note at or start a Live Chat. We’d love to hear from you.

Meet the Most Secure Console Servers on the Market

Subscribe to Blog Updates