Accounts Window

Configure who can log in to KeyServer with KeyConfigure or the Web UI and what permissions they receive.

Note you can also modify these items in the Web UI. The Web UI has additional options to set the default Forms used by an account when working with detail records in the Web.

It is common to want to give multiple Administrators the same set of Privileges. Note when we use the term Administrators we mean authenticated users, regardless of permission level. Roles define a set of privileges, which are then linked to Accounts. Accounts themselve have no inherent privileges, they must have one or more Roles to assign them. Privilege is only half of the permissions structure, the other half is ACLs which grant access. ACLs can be assigned directly to Roles, or you can leverage admin Groups (note, not the same as the objects in the Groups window) which in turn are assigned to ACLs for more granularity.

ACLs indicate which records within a single database (Computers, Purchases, Policies) are accessible. You might want a certain admin to edit computers, but only computer asset details within a certain Division. The Privilege to edit computers is granted by a Role, and the Access to a given division of computers is granted by ACLs. The relationship between Accounts, Roles, and ACLs is further explained in Administration and Management. For information on authentication from an external source like Active Directory, see Admin Authentication. By leveraging external authentication, the creation of Accounts that are assigned Roles based on something like AD groups can be fully automated.

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 Access 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 or Folders.

The Accounts window has three categories of objects: Accounts, Roles, and Groups. 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 (type Account) 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. The built-in Roles can be used as is, and many are prebuilt examples that may fit a generic need. Any additional custom needs can be accomplished by creating your own 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, you will see its Account Details. Be careful when right clicking to make a new account that you choose the proper type, internal or External.

Special Accounts

By default, KeyServer has several built-in Accounts defined, some of which are of particular interest: Administrator, Manager, External Report Account, KeyReporter Guest, KeyReporter Schedule, and Community.

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 the Web UI 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 by 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 (the process that runs the Web UI and scheduled Reports) 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. Again, in the case of a Standalone KeyReporter additional configuration is needed.

External Report Account

The External Report Account will not be available for use by external reports until you assign it a password. The Windows KeyConfigure installer (ksp-admin) creates a default DSN (ODBC) 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 account can be useful when leveraging 3rd party tools like Crystal Reports, or you can make custom accounts for such a purpose.

Manager

This account is essentially the same as Administrator and holds that Role. It is designed to be used in Admin Authentication when performing a simple configuration with external authentication. You can simply route all users in a given external group to use this account. It is a shared experience despite using individual credentials to log in. As a result, you would not know from logs which admin performed an action, only that someone with access to the Manager account had done it. Because of this, many sites will opt to have individual accounts created, which also allows personal Dashboards in the Web rather than a single shared view.

Community

This account is essentially the same as KeyReporter Guest in regards to rights. Like Manager it is used in a simple secure environment where KeyReporter Guest is disabled, forcing all users to log in. By routing all unknown logins to Community in the Admin Authentication, you have a fully authenticated environment that still has Guest level access. You can however more easily modify the Community account as compared to the Guest account, thereby granting your "everyday users" higher access if desired. This may be used in small business settings more than Education.

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. For full details on the settings available in Roles, along with notable Privileges, see Role Details.

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 Software Support if you need help with configuration.

Groups

As mentioned above, Groups are a sort of container for applying ACL permissions. 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 Software 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.