Sections partition the computers of a single KeyServer into distinct sets to facilitate Federated Management.
A KeyServer always has Enterprise level Administrators who can see and configure everything (all computers, policies, etc). Once Sections are defined, any particular Administrator can be assigned to a Section, and Access rights are automatically set up so that Administrator is then able to configure computers, policies, and purchases just within their assigned section.
Sections apply to a variety of different objects in K2 - Computers, Purchases, Policies, and Users. However, an integral part of specifying what each Section means is determining which Computers are part of each Section - so configuration starts in the Computers window.
By default, the Computers Window shows a single Uncategorized Division which includes all computer records. Our use of the word Division refers to dividing up the computers at the finest level of granularity. Sections, in turn, can each contain multiple Divisions. Sections should be created to align with management goals, since they help delegate management to different Administrators. Divisions align with some logical grouping within each Section. Often Divisions are set up as distinct physical locations (i.e. rooms or buildings), but they do not have to be. Of course, these words may or may not correspond to the way they are used in describing the structural hierarchy of your organization.
Now we will look at some simple configuration of Divisions and Sections. First we have discovered some client computers. Right-click in the Divisions part of the Computers window and select “New Division....” to create additional divisions. Then select computer records and drag them explicitly into an appropriate Division. Note that divisions can also be applied automatically - either using rules (see Computers Window documentation for more), or based on properties queried from an External Authentication source.
For a small organization, or one with simple, centralized management, we could stop here. A single Administrator can see all Computers, and can create Purchases and Policies that apply to all computers. A KeyServer that has been upgraded to v7.3 or later from an earlier version will also look much like this - Divisions created in an earlier version are preserved, but no Sections are created automatically. Sections are entirely optional.
Imagine, though, that we want one to create an Administrator who is responsible for computers in ADAMS and DAVIS, and another who is responsible just for WILSON. As before, right-click in the Divisions list, and this time select “New Section...”. This brings up a Section Details window.
Divisions can be added to the list in this Details window, or they can be dragged directly within the Divisions list of the Computers Window onto a Section. It is not necessary to assign every Division to a Section - some Divisions can remain outside of all Sections. This simply means that there is no Section Manager who can manage those computers - only the Enterprise level Administrators have control over computers in those Divisions.
Having created Divisions and Sections, we are now ready to create Section managers. Switching to the Admin Access Window, we see various built-in Roles and Accounts. In the Groups list, there is a single built-in group named “Viewers”, but two additional Groups have been created, one for each Section. These groups will help to ensure appropriate Access Rights for Section level Administrators, but for now we don't need to manipulate them directly.
Right-click in the Admin Access window and select “New Account...”. As we have seen in other instances, this brings up a new Details window. Next, drag the “Section Manager Role” into the “Roles & Groups” pane of the Details window. This Role will grant privileges that are typical of a Section Manager - e.g. the ability to log into KeyConfigure, view and modify most objects such as Computers and Policies. The Section Manager Role does NOT have more powerful privileges such as the ability to Create new Roles or Accounts, and cannot make global changes such as configuring Authentication or Exporting.
Next, drag the “East” Section from the Computers window into the “Default Section” field in the Account Details. Now Save the window without closing it. Notice that after saving, the Roles & Groups list also shows the “East Managers” group, even though we did not explicitly drag it in. It has been added automatically since we assigned Bob to the East Section.
Now that we have created a Section Manager named Bob, log out as the main Administrator account, and log in as Bob instead. So far we have only done anything with Computers, so logged in as Bob, take a look at the Computers window.
Right away, you will see that the entire North section is dimmed. We can see that it exists, and we can see the Division names, but we cannot see any computers within that division. On the other hand, we can still see computers in the Uncategorized division, as well as the Kiosks division. Both of these divisions have not been assigned to a Section. If we open some computer details though, we will notice that we can change computers in our own Section - for example adding notes or changing the Login type. But for computers outside of our Section, we have read-only access.
Next look at the Policies Window. First of all, as Bob, we can still see any Policies that were created by the Enterprise Administrator - but just as in the Computers window, we cannot modify these Policies. Having at least read-only access to Enterprise wide Policies is important, since these Policies will apply to the computers in our assigned section. So we should be able to see that these Policies are configured. Now right-click in the Policies window and select “New Policy...”. Step through the wizard and get to the Policy Details window.
Notice in the “Scope & Action” that our Section, East, has automatically been filled in. Furthermore, while we can edit the Policy name, Metric, etc, the Section is the one thing we cannot change. Because there is a Section, this Policy will only apply to that Section. The important thing is that as a Section specific Administrator, we can only make a Policy that will apply to our Section. We cannot (accidentally or otherwise) apply a Policy to parts of the Enterprise.
Sections have been designed to cover a common use-case in IT Asset Management - a concept often referred to as Federated Management. Essentially Federated Management just means that Administrators can be assigned to a specific sub-set of a broader enterprise, and are then responsible just for that sub-set. We call each sub-set a “Section”, and implement functionality to make this type of management easy. In our default configuration, Access Rights do not have to be explicitly specified unless you want something other than the following configuration:
Note: If you upgraded from a pre-7.3 version of K2 you will probably need to change the configuration which has been carried over from the earlier version in order to make Permissions for Section admins work as described above. Contact Sassafras tech support for help.
For an overview of how Access Rights and ACLs work, see the Administration and Management documentation.