Account Limitation - Separate Shut/No Shut from Node Management

NCM meets you in between giving hands-on CLI access to a network node and having a user just click a button--if you have NCM.

I suspect you could set up NCM user rights to allow them to run canned scripts from NCM to specified nodes.  You pre-build the scripts, those users run them on the selected nodes.

But once you've had to build enough scripts and adjust enough permissions, you're probably better off training employees to operate the CLI remotely and force them to use TACACS to login and accomplish every task.  Sooner or later they'll have to be trained to the point at which they can be trusted--or be fired.  Why not build up that skill set now so these employees can become trustworth?  They'll end up becoming more effective helpers later.

In some instances, yes, we could give access to the equipment and they could do this. But we're also wanting to allow some individuals this level access in UDT because it is much simpler to push a button or train someone to push a button than to go into a CLI and enter in some commands.

I'd definitely be up for further conversations around this topic.

My own operational experience reflects Rick's first observation; in an environment where you have non-repudiation, there are no "anonymous" users that can exercise those functions.  So - there's accountability. The other option is to address this on the device side with more granular access controls, which would prevent someone from just bypassing the management platform altogether. But it's more effort to set up on the devices, unless you are driving the config with a "standard" template from a tool like NCM.

As Rick points out, we don't have granular RBAC in Orion at this point.  I'm curious if his proposed workaround is practical for you?

One of things we've been thinking about is how we make more UDT more useful for non-network-admin users, and perhaps more generally useful to a broader set of users.  Would you be interested in having a more in-depth conversation about this?

jreves​

I understand the need and the concern.  You could do it If:

• Those support staff were in a unique AD group
• You used AAA TACACS that referenced that AD group
• Your permissions to that team only allowed the commands you specify.  For example, instead of allowing shut and no-shut on a port you could allow that team only access to the Cisco commands "power inline never" and "power inline auto".  Now you're leveraging AAA in the way it was designed.  It'll take some serious thought, and requires them to have SSH access to the CLI on those devices.  Maybe you don't want that?

I recognize it would be nice to do this from SolarWinds administrative rights, but it seems too granular for the current state of NPM's art.  I'd be happy to be proven wrong by people like adatole​ or serena​ or sqlrockstar​ or their peers.

Sorry for the delay in providing a better explanation of my use case.

I wholeheartedly agree with your statements rschroeder. The group in question is not a "networking" group. They however have devices that utilize POE and in order to provide them a better service and ultimately remove the network group from initial troubleshooting we wanted to provide them access to their interfaces to allow them access to shut/no shut without us. Regardless of our policies though, I feel like node management within the application and the ability to shut/no shut interfaces are very different things and it didn't seem programmatic to be linked. I felt with all the separation with in the administrative section with regards to the different modules it was odd and unexpected that this UDT feature was tied to that setting. This is my opinion and while I feel this way others may not. I'm someone who likes granularity and the more granular I can be with roles the better.

Help SW Admins out with your worst-case scenario of users being given Node Admin rights.  What do you fear they'll do?  Delete nodes?  Change configurations beyond changing port up/down?

Really make your case as strong as you can, and then step back to see if it's as bad as you fear.

Things that should make you trust your staff with Node Admin rights include:

• You've trained them well, explained you've given them the keys to kingdom, and that you're trusting them to only do what's necessary, never taking an action or making a change for which they don't truly know the end result.
• You've got NCM backing up configs, so you can do a fast restore if there were problems.
• NCM is set up to send real-time configuration change notifications to you and your peers, so you know what just happened.
• You're using AAA with TACACS on all your nodes, so you have  full paper trail of who issued what commands on which nodes.
• You require everyone to submit Change Requests to your Change Administration Board for review at least three days before any change is to be performed.  And anyone has the right to ask questions or postpone or deny a Change Request if they don't understand it or its ramifications.
• Your company requires specific types of network changes to be performed outside of business hours to reduce or prevent impact to customers or employees.
• Your company has a written policy explaining expectations and consequences, and anyone who violates it understands they can be fired or sued for damages.

If you've set your staff up to succeed, they should.  If you don't trust them, replace the bad apples with good ones.

Once everyone understands "cowboy networking" is not allowed, that there's a paper trail leading right to the person who makes the inappropriate change, and that their reputation and job are on the line, you've got a professional corporate solution that should be hiring and training good people who can be trusted with those keys to the kingdom.

However, I'm a control freak, and I don't want to give out those keys to someone I haven't personally vetted.  Despite having all those assurances in place, I still worry someone will do something inappropriate that will cause problems for some subset of my 17,000 employees, and that I'll be called in to troubleshoot and correct the issues (at stupid-o'clock-in-the-morning-on-a-weekend).  I have to get over my trust issues.  Maybe others of us do, too?