Have you ever been asked by someone for access to a report or set of reports and spent ages in the Notification Server trying to figure out how security works and how to set it up? Usually the answer has been to give that user administrative rights rather than spend time trying to figure out how to give them permission to see just one folder or a set of folders. Either that or create a report and simply email it to them. Security within the Notification Server can get quite confusing when you start getting into roles, privileges, permissions and inheritance. I for one have been spending a lot of time trying to figure it out and have tried to make the topic of securing the NS as easy as possible.
This guide tries to explain the whole security process in a simple way to make it easier to understand and secure your Notification Server.
The Difference Between Role- and Scope-Based Security
You will hear this term a lot. Sales people will use it without knowing what it is, systems engineers will use it when they know what it is but never need to figure it out and it's something that needs some clarification.
The Notification Server uses Role and Scope based security to establish which users get access to which specific areas and items within the Altiris console. Before we get into how everything works together we need to explain a bit about both Roles and Scopes.
Role Based Security
A Role in terms of Altiris security is a collection of users or groups that share common privileges. Users can be domain users or local computer users and groups can be domain groups, local computer groups or Notification Server specific groups. A privilege is a task that can be performed within the Notification Server such as creating collections, editing SQL, creating policies, viewing tabs or reading reports.
There are a number of created by default on the Notification Server computer when you install Altiris.
Altiris Administrators: Basically allows full access to all areas of the Altiris Console. You cannot modify this role to prevent you accidentally locking yourself out of the Altiris system.
Altiris Guests: Gives you basic access to the reports tab.
Altiris Level 1 workers: gives access to all the tabs in the Altiris console and also allows viewing and editing of helpdesk incidents as well as creating bulletins.
Altiris Level 2 workers: gives similar privileges as level 1 workers but can also create collections, shortcuts, notification policies and agent settings.
Altiris supervisors: this role gives access to all tabs, manage workers and incidents within helpdesk as well as creating and modifying reports, notification policies, collections, security settings and tasks.
As you install different solutions you will notice that more default roles get added to your list.
You can also create a new role you may need by going to View > Configuration and then going to Configuration > Server settings > Notification Server settings > Security Roles.
If you click on any of the listed security roles you will be able to see current members and privileges that have been assigned to that role. Once you define which roles you will need within the organization you can add or delete roles as required and setup the relevant privileges. This makes it much easier to manage when you add new users into these roles.
Scope Based Security
I find it easier for Scope Based security to be known as Security permissions. Scope Based is simply the permissions set on individual folders and items (such as reports) within the Altiris console. A real life example of this would be that under the reports section of the Altiris Console you have reports for Desktop management and reports for Server management. Obviously you cannot set permissions on the report tab as both administrators need access to the reports but you can set permissions on each set of reports so that the Server Administrator can see server reports while the desktop administrator can see desktop reports.
Because inheritance is available you can set permissions on the desktop reports folder and let these permissions flow down to any report that is contained within the folder. Just like with Roles you get some default permissions when you install Altiris solutions such as Delete, Read, Write, Change, Clone and Apply. The local administrator and Altiris Administrator role are automatically granted all permissions on all the Altiris tabs and items but you will need to configure the other roles.
The Security Role Manager
The security Role Manager is where you can apply both your scope based security and your role base security together, i.e. apply permissions to each of the tabs and items for each of your Roles within Altiris. To access the security role manager console go to Configure > Notification Server > Security Role Management.
There are a few areas to touch on in terms of navigating around the console. Along the top right hand side of the console you will see two drop down lists. The role drop down and the filter drop down.
The Role Drop down lets you select one of your defined Roles so that you can edit the permissions and settings.
The Filter Drop down lets you select which object types you want to see permissions for (i.e Reports tab, Collections, and Tasks.) When deciding on permissions it is worth making decisions based on the Altiris 6.0 console as it uses tree views where the Altiris 6.5 console uses menus. Investigation would have to be done to figure out if the Altiris 6.5 console works perfectly with the security role manager.
When you select your Role and Filter you will notice that the left hand window changes to show you exactly what the user would see if logged in under a specific role. This is a good feature as it lets you see what the user would see without having to log out of the system and log back in as a user before realizing that you have made a mistake with your permissions.
Other Things to Note
Inherited and Non-Inherited Permissions
You will also notice that you can see two areas where permissions are listed, this is where you can modify Non-inherited permissions for each Role. You will notice that inherited permissions are grayed out as you cannot modify these.
As mentioned earlier Inherited permissions are set at the top of the tree and flow down to everything under it and usually this is the easiest method of controlling permissions.
Secure as You Go
If you choose not to use inherited permissions you can always secure individual reports, tasks and folders by selecting the item, right clicking and selecting properties. Once you are in the properties page you can click on the security tab where you can see each of your roles and assigned permissions. You will notice that there will be a number of roles already listed, most of which has its permissions grayed out. This due to the inheritance rules that are flowing down from the top of the tree. You can click on the add button to add in new roles that you have created within your system.
The easiest way I found to get my head around the security was to ignore the default groups that come with the installed solutions and create a new role and set some basic privileges and permissions. I then log in from another machine and see what I can and can't see. After a few tweaks you will start to get a basic template on which you can base new roles that you want to add to the system. It is much easier to work out which permission changes affect the users console when there are no other inheritance rules that overwrite the permission change that you have just made.