In this video, we'll 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 straightforward.
Just keep in mind that these aren't universal settings.
There just settings for this user.
For instance, 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 you handy if you have contractors working
on the system or someone has turned
in their two-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's 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 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 wanna spend
my time building other peoples' 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 of 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 alters 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 wanna 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?
Well, that 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
to 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.
All right, in the next section here, is where we're going
to assign the views that 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 from 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 you're 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 homepage 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 homepage 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 homepage view
notice the default network device line,
if the homepage 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.
All right, 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.