Configure who can connect to KeyServer with KeyConfigure. Use Roles to control which actions can be performed by each Administrator.
It is common to want to give multiple Administrators the same set of Privileges. Roles are where privileges are defined. Then individual Admins are associated with appropriate Roles, and Privileges for each Admin are granted based on Role membership. For example, the Report-only role is applied to several accounts, and grants these accounts the ability to create and view reports.
Note that Roles do not indicate which records within a single database (Computers, Purchases, Policies) are accessible. You might want a certain admin to see information concerning computers, but only computers within a certain division. Rights to view individual records are granted separately, to allow fine-grained control over what each administrator can access. The relationship between Accounts, Roles, and ACLs is further explained in Administration and Management.
When creating a new account, you should be sure that the account has appropriate Privileges (inherited via associated Roles) and also that it has appropriate Rights to the various main objects in K2. Access Rights can be configured at a global level (via the Server ACL), on a database by database level (via the default ACL for each database), or on more specific objects such as individual Divisions.
OPEN KeyConfigure Admin Access window
By default, KeyServer has four Accounts defined: Administrator, External Report Account, KeyReporter Guest, and KeyReporter Schedule. The Admin Access Window shows these four Accounts in the bottom section. In the top section it shows the built-in Roles. Some of these are associated with the four default Accounts, and define the necessary privileges for those Accounts. Others are useful defaults that you can use as needed. The middle section shows Groups, which are used to specify Access Rights on specific objects. For more about the general way in which Roles, Groups, Accounts, and ACLs relate, see the Administration and Management documentation.
Notice that there is an Account named Administrator as well as a Role named Administrator Role. Looking in the details for that Role, we see that it has a single member, the Administator Account, and that it has all privileges.
The Administrator Account is like the root account for a computer. It can always be used to login, and it has the Administrator Role, which gives it Full privileges. The password for the Administrator Account may be changed, but the Administrator Role cannot be removed from it. Additional Admins can be given the Administrator Role as a convenient way of giving all privileges while using a different name and password. The privileges on the Administrator Role cannot be edited since this is a built-in Role.
Now look at the Account details for KeyReporter Guest:
This window shows an Account as opposed to a Role. Account Details also have a Privileges panel, but in this case the Privileges are not editable. Privileges cannot be set for Accounts. Instead, this panel shows what Privileges the Account has via the Roles associated with that Account. So, we see that this Account has Custom Privileges, and we could look at which individual privileges are listed by expanding the various topics. In the Roles & Groups panel we see that the Public Role is the one giving this Account privileges. The Viewers group ensures that KeyReporter Guest Account can report on all objects (Computers, Policies, etc). We can double-click any Role in order to see the details for that Role. For example, here is the Report-only Role:
We cannot change the Privileges in this Role Details window because it is a built-in Role. Both default Accounts with the Report-only Role are there to give a default way to integrate with KeyReporter and external reports. The Report-only Role does not allow logging in to KeyConfigure — it is only useful for KeyReporter or for getting data through ksODBC. Likewise, the Public Role is specifically set up for the KeyReporter Guest account.
Notice the Group field. This is only useful when Admin Authentication is configured. It refers to a Group as defined in the external authentication method, not an internal Account Group. When an admin logs in using a name and password which are not explicitly configured in the Admin Access Window, but which authentication recognizes, the login can succeed even if the External account has not been explicitly created in K2, if the authentication module gives that name membership in some group which is associated with a Role.
The guest account in KeyReporter controls what a user can see in the KeyReporter interface before they have logged in. KeyReporter Guest is the pre-configured name which KeyReporter will use to connect to KeyServer when a guest tries to access KeyReporter. The Account record in KeyServer has a password, just like any other account, but generally the password is unimportant since it will only be used between KeyReporter and KeyServer - never typed manually be a person.
KeyReporter Schedule is very similar to KeyReporter Guest. When KeyReporter needs to run Schedules, it uses the KeyReporter Schedule account. Just like the Guest account, you likely will not need to set a specific password, instead relying on the random default password. Note that the Proxy Role is what gives the KeyReporter Schedule Account the ability to run reports on behalf of other Administrators.
The External Report Account will not be available for use by external reports until you assign it a password. The Windows Admin installer creates a default DSN configured for external reports to access the External Reports Account with password "Sassafras". If you assign a different password (for better data privacy) you will have to re-configure the DSN (using the Window's ODBC Administrator tool). Note: this account can be deleted, but then it will be recreated the next time you start up KeyConfigure and you will have to again assign a password to enable the account.
This Role is not associated with any Accounts by default. It is there because it might be useful for additional Accounts that you define. By default it is given ACL rights to all objects, so the "Scope" of someone with this Role would not be limited at all. But the Privileges specified in the Role are not as extensive as the Administrator Role. This Role is meant for an Admin that should have visibility into the entire Enterprise, but should not have control over most of the global KeyServer options and settings. With default ACLs in place, assigning just this Role to an Account is sufficient to grant Privileges and also give Access Rights to all objects.
This Role is not associated with any Accounts by default. It is meant to be a useful Role for any Accounts for which you specify a Default Section. Via ACLs, this Role gives visibility into Enterprise Computers and Policies (those that do not belong to any Section). It also specifies a core set of Privileges that should be appropriate for Section level Admins.
If you create Sections in the Computers Window you will see that additional Groups will be created automatically. For example, if you make a Section named "East", you will see a group named "East Managers". This group is in the ACL for the East section, and is automatically applied to any Account for which you specify East as the default Section. The end result is that by setting the default Section for an account, that account can automatically Administer the objects in that Section - Computers, Policies, and Purchases. You can manually modify membership for this group, or change which ACLs refer to this group, but most likely you will not need to.
There are a number of additional built-in Roles. Double-clicking any of them will show the details window, and the Notes field contains a description of what they are intended to be used for. Note however, that unlike the Enterprise Manager Role and Section Manager Role, these additional Roles do not appear in any default ACLs. So for example, if you create and account that has the Purchasing Manager Role, you will also have to do additional configuration so that this account will actually be able to see any Purchases. You could turn on View/Inspect/Modify rights on the Server ACL for Everyone but note that this will disable Section Managers - allowing even a Section limited account visibility into all objects. Instead you might create a new group, add it to the Server ACL with all Rights enabled, and make your new account a member of this group in addition to having the Purchasing Manager Role. ACLs can be complex - contact Sassafras tech support if you need help with configuration.
The Privileges Pane allows you to view/edit Privileges for an Account or Role. For Accounts, privileges are read-only, and are listed so that you can understand what privileges are available to that Account as a result of the associated Roles (especially useful when the Account has more than one Role). The special Administrator Role always has all privileges. Other Roles allow you to edit privileges for that Role. Clicking on the expansion icon next to any group will show the individual privileges within the group. The privileges available to the Account or Role are listed with checkmarks next to them. For a Role, clicking to the left of a privilege (where the checkmark appears / would appear) allows you to toggle the privilege on or off for the selected account. Note that some of the privileges are “linked”. That is, if you disable one, it may automatically disable others as well. For example, in the Policy Privileges group, if all the privileges are enabled and you disable View Details of Policies, Change Details of Policies will also get disabled. This makes sense, since if you cannot even see the details of Policies, you clearly shouldn't be able to change them.
The name of each privilege should be self-explanatory, as long as you are familiar with the KeyConfigure interface.
Setting privileges for various Roles allows you to control what each admin can do. You can also control which objects they can see. For example, right-clicking on a Division, in the left hand side of the Computers Window, will let you Edit ACL for that Division. This will allow you to specify permissions on that specific Division for any number of Accounts, Groups, or Roles. These Permissions apply whether reporting in KeyReporter, or logging in to KeyConfigure. For more on Access Permissions, see the ACL Details Window documentation.