Administration and Management

Management of all but the smallest KeyServers will typically be shared between multiple Administrators, each of whom has different responsibilities, and therefore different levels of access to the configuration and information on the KeyServer.

The Admin Access Window lists the Admin Accounts that can connect to KeyServer, the Admin Roles that each define a set of privileges that accounts can have, and Admin Groups that simplify how rights to various objects on the KeyServer are granted. Initially, KeyServer creates some built-in Roles, Groups, and Accounts that might be useful at any site. New Roles can be created to represent the various types of activities that Admins will need to perform on your KeyServer. You can add new Groups to simplify how you grant access to the Computers, Policies, Purchases, and other objects on your KeyServer. And of course you will want to create an Account for each person who will be managing KeyServer, running reports, or otherwise viewing activity in KeyConfigure or KeyReporter.

Roles, Groups, and Accounts

The Admin Access window lists all of the Roles, Groups, and Accounts.

Admin Accounts can be created for the people who will need access to the management and reporting features of KeyServer. An account either has a local, KeyServer-specific password, or is linked (by name) to an external source for authentication. Accounts by themselves do not have any rights or privileges to the KeyServer. Instead, an account gains privileges and rights by the Roles it is assigned, and can gain further access to the data on KeyServer by membership in Admin Groups.

Admin Roles each define a set of privileges to be assigned to any Accounts that serve the particular Role. A Role typically has multiple related privileges that are needed in order to complete the tasks that will be undertaken by the Accounts in that Role. Multiple Accounts can have the same Role, and each Account can have more than one Role.

Admin Groups are similar to Roles in that they hold rights that are then granted to their member Accounts. Groups can contain more than one Account, and any Account can be a member of more than one Group.

Privileges and Rights

The basic purpose of Roles, Groups, and Accounts is to determine who (an Account) can access what (a configuration setting, a management task, or an object like a Computer or a Policy). Notice that in describing Roles and Groups above we used two different terms: privileges and rights. A Role has privileges that will then be given to any Accounts with that Role, while a Group has rights that will be given to any Account in that Group.

So what is the distinction between a privilege and a right, and when are they needed? Consider this analogy: In order to legally drive a car you must first obtain a driver's license. This license gives you the privilege to drive. However, that doesn't mean you can just drive away in the next car you see. To drive a particular car you must have its key, which in our terminology gives you the right to drive that car. So, in order to legally drive a particular car, you need the privilege to drive generally (driver's license) and also the right to drive that car (the keys).

To apply this analogy, take for example a particular Account and a particular Policy. Can the Account view the Policy? First the Account needs the general privilege to "View Policies", which it might have by being assigned a Role that has that privilege. Then the Account must also have the right to view that specific Policy, which perhaps it gains by virtue of membership in a Group that has the right to view the Policy.

Just like someone can have a driver's license but not the keys for a given car, an Account can have the general privilege to view Policies (for example), but not the right to view a given Policy. And just as a 5 year old who holds the car keys does not have the privilege to drive that car, an Account can be a member of a Group that has the right to view a Policy, but without the privilege to view Policies in general, an Account will not be able to view that — or any — Policy.

The analogy above applies to privileges and rights for objects you create or manage in KeyServer (Computers, Policies, etc). Another type of privilege pertains to the configuration settings and other actions that can be performed within KeyConfigure and KeyReporter. For these cases only the privilege is required — there is no separate right. Examples include the privilege to log in to KeyConfigure, the privilege to run reports, and the privilege to change how KeyServer exports its data. In either case, privileges are given to an Account in the same manner, via the Roles assigned to that Account.

Access Control Lists and Inheritance

You can customize access to five types of objects: Computers, Policies, Purchases, Reports, and Users. Objects within KeyServer are organized into an access hierarchy. At the bottom of the hierarchy is the individual object. Objects can be contained within Folders, and Folders are contained within Tables. Finally, at the top there is the Server Root.

The items at each level of the access hierarchy have an Access Control List, or ACL, that describes the rights granted for the objects lower down in the hierarchy. Each entry in an ACL references an Admin Group (or Role or Account) and specifies which rights are granted.

To determine what rights an account has for a given object, KeyServer starts at the individual object's ACL. For each entry in the ACL, if the referenced group contains the account, the entry's rights are added to the rights that will be granted. If multiple entries apply to the account, the rights are combined. KeyServer then goes to the object's containing folder (if appropriate) and adds the rights granted at the folder level to the account's rights. The object is said to inherit the ACL rights of its containing folder. After the folder ACL, KeyServer looks at the enclosing Table ACL, and finally moves to the Server Root ACL. In other words, the folder inherits ACL rights from its enclosing Table, and the Table inherits rights from the (singular) Server Root.

At any level an ACL can be marked so it does not inherit rights from its parent. Inheritance should only be stopped in this way under certain special circumstances, since doing so can make the access configuration difficult to manage. Note that ACLs can only be used to grant rights. There is no way to deny rights via an ACL if the right is granted by another ACL along the path. This means a right only needs to be granted in one ACL along the path from the object to the Server Root.

For Computers, Policies, and Purchases there is a secondary inheritance hierarchy that aligns with an object's Section. Each Section has an ACL that is inherited by the Divisions, Policies, and Purchases that are associated with that Section. There is an Enterprise ACL that is inherited by the Divisions, Policies, and (optionally) Purchases that are not associated with a Section. Most likely, the only time you would need to restrict access of an Admin is when using Sections and Section-specific Admins. The default ACLs are carefully designed to handle most common configurations in an expected fashion, so even in this case you might not need to change ACLs. For more about Sections, refer to the Sections documentation.

General Guidelines

Configuring and managing access for many Accounts to all of the objects within a KeyServer has the potential to become very complex. To reduce the complexity of this task you should follow a few simple guidelines. It's sometimes neccessary to diverge from these guidelines when special circumstances arise, however in all but a few cases the simpler approach will suffice.

Create Roles to define common sets of privileges needed by different Accounts. There might be a number of admins who need to change settings of the KeyServer. Maybe these admins also have other responsibilities within KeyServer. Instead of creating a Role for each combination of privileges, create a "Settings" Role that can be assigned to the appropriate accounts, and use other roles to add whatever additional privileges are needed by those accounts.

Create Groups to grant different levels of access to the objects within KeyServer. Before granting a specific Account access to objects, consider instead creating a group to which that account can belong and granting that group access. This way, if you need to make other accounts that will need the same access rights, you can simply add those accounts to the group instead of locating all the various objects to which they will need access.

Change ACLs as high up the inheritance hierarchy as possible. Changing the ACL of an individual object is usually not needed. It is better to change the ACL for the objects container (Folder, Section) since typically all the objects in a container should be treated similarly. Likewise, instead of changing all of the Folder ACLs in the exact same way, change the table's ACL or the server root ACL.

Rely on the automatic, default behavior as much as possible. The object access mechanism in KeyServer has been designed to handle the majority of configuration requirements you are likely to have. Smaller KeyServer can possibly ignore the underlying ACLs altogether since there is not a need for many KeyServer Admins. Medium and large sites where KeyServer's Sections fit well in the organization might find that the Section ACLs provide the best combination of control and simplicity.