Admin Access Window
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. For specifics on ACLs see ACL Details Window. For information on authentication from an external source like Active Directory, see Admin Authentication.
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. 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.
The Admin Access window has three sections (not to be confused with the Section column): Roles, Groups, and Accounts. The Type column shows these 3 object types and notes if they are built-in.
Roles are sets of privileges that can be granted to an account either manually or automatically by use of External Groups.
Groups are containers that can be used for easy assignment of ACLs to objects by adding an already configured group to an account.
Accounts are the individual users who will access the system and can be either internal or external.
There are several built-in Roles, Groups, and Accounts which for the most part can not be modified or deleted because they are critical to default operation. Viewing these will show their interconnections, and generally speaking you should not seek to modify these. Any additional needs can be accomplished by creating your on Roles and Groups as well as internal Accounts if needed.
Accounts
There are two types of accounts, internal, and external. External accounts are typically created automatically by use of Roles and external authentication as detailed below, and will be labeled as Type External. Internal accounts are simply Type Account and exist entirely inside KeyServer. You can make accounts as needed, but users with Active Directory often prefer the external option. When creating an account or viewing its details by double clicking, there are several panes of information that can offer configuration options.
Settings
Roles & Groups shows all Roles and Groups assigned to the account. They can be removed by right clicking on them and choosing Delete, and can be added by drag and drop from the Admin Access window.
Notes are anything you want to notate on the account for your own reference.
By default, KeyServer has four built-in Accounts defined: Administrator, External Report Account, KeyReporter Guest, and KeyReporter Schedule.
Administrator
Notice that there is an Account named Administrator as well as a Role named Administrator Role. If you double click either the role or the account you can view their details and see that they reference each other.
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. Because of it's unique nature, several options typical to an account detail do not show for this account.
KeyReporter Guest
This account is used by KeyReporter for Guest access. 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). Note however that modifications to this role will not have the expected impact in most cases. If you do not want any Guest access in KeyReporter, simply uncheck the Account is enabled option. The account 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. It is set on install, but can be modified and used in the case of a standalone KeyReporter instance.
KeyReporter Schedule
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.
External Report
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.
Roles
As mentioned, there are aspects of built-in Roles that can not be changed, like name and privileges. These Roles can be used as needed however in accounts you create when their configuration matches your desired access rights. They are provided to offer reference examples and potentially easy pre-packaged roles to apply without needing to make your own.
Notice the External Group field. This is only useful when Admin Authentication is configured, but can be used with many built-in roles. It refers to a Group as defined in the external authentication method, not an internal Account Group. This can be used to automate logins and the applied roles (permissions) for an external source. For example, a Domain user tries to authenticate for the first time and has no account yet in KeyServer and therefore no role. The server finds they are a member of an AD group referenced in the External Group field of a role and therefore makes their account and applies that role and the user logs in with the desired rights.
Note that using this functionality can not be mixed with local role assignment that is out of sync with the external group. That is, if you apply a role that points to a group to an account that is in the external system but is NOT in the group, the role will be removed on login attempt and they may therefore be prevented entirely. Similarly, if you remove the role from the account in KeyServer but they are still in the external group, it will be re-applied at next login. When using external groups in a role, you need to manage membership in that external group, not in KeyServer.
The Name field simply shows a list of Accounts that are members of this Role.
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.
Notes as always are free form for your use.
Default Roles
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.
Enterprise Manager Role
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.
Section Manager Role
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.
Additional built-in Roles
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 name of each privilege is largely self-explanatory, as long as you are familiar with the KeyConfigure interface. There are some that are used for internal purposes, future planning, or deprecated features however, so again if you have questions please contact support.
Groups
As mentioned above, Groups are a sort of container for applying ACL access. Although applying ACLs to a Role is the most simple and straight forward course of action, complex environments may need to use Groups instead. Note while you'll see a warning when applying an ACL to a Role that you may want to use a Group, there is nothing wrong with using a Role. Imagine for example you wanted two groups of people to have the same privileges to objects, but you wanted that to apply to different objects. You could either create two identical Roles and apply their ACLs to different objects, or you could have a single Role and two groups. You would then apply the role to all users, but the groups to select users.
Groups also have a field for External Group as Roles do. The intent is that you would have an hierarchy in your AD for example, where 20 users were in one composite group, and then 10 each were in two other groups. The large group would be referenced in the Role, and the child groups would be referenced in the two Groups. Again, this is complex by design for federated environments and by no means required. Your configuration may be very simple and never use groups. Contact Sassafras tech support if you have questions and would like to discuss this topic further for clarity, we know it gets complex!
Auto-created groups for Section Managers
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.
Limiting “Scope”
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.