Hide this message
Looking to compare latest NPM features with previous versions of NPM?
The NPM new feature summary offers a comparison of new features and improvements offered with this release.
Updated March 11th, 2016
This video demonstrates how to set up user permissions and provides best practices on which permissions should be enabled for administrators and users.
Orion Platform v2016 and above
Server & Application Monitor v6.2.4 and above
Network Performance Monitor v12 and above
Network Traffic Analyzer
|Storage Resource Monitor|| |
Network Configuration Manager
Web Performance Monitor
IP Address Manager
User Device Tracker
VoIP & Network Quality Manager
In this video, we will talk about managing your Orion users. Adding new user accounts in Orion is pretty simple, but it’s also a very front loaded process. Here’s what we mean.
This bottom section is going to be dependent on which Orion modules you have installed, so your list of applications may not necessarily match mine. So I’m not going to go through all the individual application settings because it may not be relevant for you in the first place, and in the second they’re pretty straight forward. Just keep in mind that these aren’t universal settings, they’re just settings for this user. For instance under Server and Application monitor settings, you could change the default temperature unit from Fahrenheit to Celsius for this user.
But I’ll let you read through whatever application settings you have based on your environment and I’m going to jump back to the top of the page and go through the top couple sections, beginning with the basic permissions.
First of all, do you want the account enabled, yes or no? It will probably be more useful if it is enabled, so I’ll say yes. You can add an expiration date to the account if you want, which could be handy if you have contractors working on the system or someone has turned in their 2 week notice.
Now, Disable session timeouts, yes or no? If this user stays logged in to the web console indefinitely do you want Orion to kick them out? I’m going to say yes.
Allow administrator rights. Now this one you need to be careful with because administrator rights is an all or nothing deal. If you give someone admin rights, nothing else you do matters because they can just change anything they want. There is no hierarchy to admin rights. In fact they could delete your administrator account if they wanted to, so obviously be careful with who gets admin rights.
Allow node management rights. This one is also an all or nothing deal, but it only applies to the nodes the user can access; just the nodes they can see. So if you’ve got a set of application group owners and you want them to be able to manage their own servers, you’d need to give them node management rights. But if you do that, then by default they’d be able to get into and manage any node in the system, which isn’t necessarily what I want. So in that case I might add an account limitation to restrict which nodes the application group owners can see. We’ll add the account limitation in just a minute, but now on to Reports.
Everybody, all web console users, has permissions to run existing reports. But if you want people to be able to build their own reports, you’ll need to say yes to Allow Report Management Rights. This is actually one permission I generally give to just about everyone. As the Orion administrator, I don’t want to spend my time building other people’s reports. Let them do it themselves.
There could be some concern that a user could mess up someone else’s report. If that’s really a worry, then you can assign a Report Limitation Category. This will limit which reports a user is able to see. But note that new report limitation categories are created in the report editor. In order for me to be able to restrict this user to the Application Reports limitation category, I would've needed to create at least one report and assigned it to that category first.
Alerts permissions are basically identical to report permissions. By default everyone can see alerts, but you must have alert management rights to modify or create new alerts. But I’d be a lot more restrictive with alert permissions than report permissions. As with reports, you can limit which alerts the user will be able to see by assigning the user to an alert limitation category. But unlike report limitation categories, I can create new alert limitation categories either from the alert editor or from the dropdown box here.
While it’s not as common to assign a report limitation category, assigning alert limitation categories can be quite useful because it doesn’t just restrict which alerts this user will be able to modify, it also restricts the alert notifications they’ll see. So my application group owner won’t have to wade through every alert in the system to find alerts about the application group.
Now Allow Account to Customize views. No! I tend to be very stingy with view customization rights. It’s just too easy for users who don’t understand what they’re doing to mess up views for other people without realizing it. If people want to create their own reports, great. But for the most part I tend to let the Orion administrator be primarily responsible for managing views.
Should the user be able to unmanage objects? It depends on their role. For my application group owner, yes, he should probably be able to unmanage his own servers to take them down for maintenance.
The next three selections are all related to whether the user should be able to manage certain alert functions. Should the user be able to enable or disable existing alerts, or should the user be able to disable alert actions, like when you have an alert that’s sending out a flood of emails? Here again, it depends on the user’s role. If you have alert management rights set to yes up above, these three options will all be set to yes by default and USUALLY these settings should match whatever you set for alert management rights. But for some roles, like a junior admin or help desk staff, you may not give them the ability to create or modify alerts, but it would make sense to allow them to manage existing alerts.
Now I’m going to jump down to Account Limitations. Account Limitations restrict what objects this user will be able to see in the web console. Setting up account limitations is identical to setting up view limitations, but where view limitations only apply to a single view, account limitations apply universally.
To set up an account limitation, click on Add Limitation and choose the limitation type. I’m going to choose Single Group and click Continue. Now I will choose which group the user should be limited to, and I’m going to select the Demo group. Once I click submit, I can scroll down and see the account limitation in place.
Alright, in the next section here is where we are going to assign the views that this user is going to be able to access. I’ll do this by assigning menu bars to specific application tabs. Menu bars are just a collection of links to specific views, and my user will see those links by hovering over the application tabs at the top of the web console.
I’ve created a menu bar for my application group owner, and I’ll assign that menu bar to the Home tab. Your list of tab choices is dependent on which Orion modules you have installed. As you add new modules, you’ll see the application tab for that module pop up. So your list of application tabs will probably look different than mine.
You can assign a menu bar to any application tab you want, and you can turn off any application tabs the user won’t need. You can also reorder the tabs if you need to.
Now that my menu bars are assigned, I’ve only got one more thing to worry about, the home page view and the Default summary view. The Home page view is the page that will load when the user logs into the web console. The Default summary view is the page that will load when the user clicks on the actual Home tab at the top of the page. Generally these two are going to be set to the same view, but they don’t have to be.
You’ll notice though that they default to Orion summary home, and that’s not where I want my user to go. I’ve created a custom view for this user, so I’ll set that as the home page view. You will need to watch this setting, because if this user is supposed to have a restricted account, you may be accidentally giving them explicit access to information you didn’t want them getting into by not changing to default views.
Just below the home page view, notice the Default Network Device line. If the home page view that you have assigned is a details view type, then that view is going to have to reference an object. The edit button to the right allows you to specify that object. So in my case, I have created a custom view for my application group owner to show all the hardware that is part of the application group. So I’ll click on edit and then choose the application group.
Alright, assuming that I have checked my application specific settings, I’ll click submit to save the user account. Now I can see the account in the account list, and I can double check my account permissions. Everything looks alright, but you should always be sure to test your user accounts by logging in as the user and checking the views and account permissions before deploying the user account.