There are two types of Tachyon roles that can be applied to the Tachyon users: system roles and custom roles.
System roles are built-in and are not configurable. The following table lists the built-in roles:
|Tachyon system role||Permissions||Introduced|
|1E Client Deployment Administrators|
Renamed in 4.1
|1E Client Installer Administrators|
Renamed in 4.1
|Connector Administrators||4.0 (SLA)|
|Custom Properties Administrators||3.0|
|Event Subscription Administrators||5.0|
|Event Subscription Viewers||5.0|
If email is enabled, this role will receive an approval request email for each requested action.
|Guaranteed State Administrators||4.0|
|Guaranteed State Viewers||4.0|
|Instruction Set Administrators|
|Inventory Administrators||4.0 (SLA)|
|Inventory Viewers||4.0 (SLA)|
|Management Group Administrators||4.0 (SLA)|
|Management Group Sync Initiators||4.0 (SLA)|
|Patch Success Viewers||4.0|
(renamed in 5.0)
|Provider Configuration Administrators||4.1 (SLA)|
|Schedule Administrators||4.1 (SLA)|
Questions, responses, actions are examples of securables. Other Consumers may create their own system roles and securables.
Custom roles can be used to define who is able to use specific Instruction Sets to ask questions, run actions or approve actions. For more information please refer to the Defining custom Tachyon roles heading on this page.
The following table lists built-in custom roles used by Tachyon Applications
|Tachyon system role||Permissions||Introduced|
|1E ITSM Connect Actioner||The ServiceNow proxy user is added to this role instead of Global Actioners so that ServiceNow users can only use instructions belonging to instruction sets assigned to this role||5.0|
|AppClarity Administrators||Create, update, delete and view AppClarity Compliance, Entitlement, License Demand and Reclaim - view and export Inventory - view, edit, delete and export Associations||5.0|
|Application Migration Administrators||Create, update, delete and view Application Migration Rules and Role Based Application Sets to manage installations in your estate during operating system deployment||5.0|
|Compliance Administrators||Create, update, delete and view AppClarity Compliance, Entitlement and License Demand - view AppClarity Reclaim - view and export Inventory - view, edit, delete and export Associations||5.0|
|Compliance Viewers||View AppClarity Compliance, Entitlement and License Demand||5.0|
|Entitlement Administrators||Create, update, delete and view AppClarity Entitlement - view and export Inventory - view, edit, delete and export Associations||5.0|
|Experience Viewers||View Experience dashboards||5.0|
|Reclaim Administrators||Create, update, delete and view AppClarity Reclaim - view and export Inventory - view, edit, delete and export Associations||5.0|
|Reclaim Viewers||View AppClarity Reclaim||5.0|
Recommendations for using global administrators
The global administrators role can be used to provide across the board permissions to a user. While this may be convenient in certain circumstances, you should be aware that this is a powerful role and should be used with appropriate caution.
Using global administrators in a lab environment
To get things up and running quickly in a lab environment you may want to make use of the global administrator role. This will help minimize the number of users required for an evaluation and reduce the initial configuration required.
To further minimize the number of users needed, you can also enable the Windows account used to install Tachyon to assume the Tachyon global administrator role. The installation account is added as the system principal user in Tachyon by the installer and it's Tachyon permissions are locked down by default. You can allow it to assume the global administrator role using the following steps:
- Create a Tachyon user from an existing AD security group
- Apply the Tachyon global administrator role to the user
- Add the installation account to the AD security group.
In the short term it's fine to make use of global administrators in this way, but this practice is not really suitable for large scale deployments and should be used with care for the following reasons:
- The global administrator role has permissions to do everything in Tachyon. It has across the board permissions to all Instruction Sets and therefore can be used to run actions that can have a major impact on your network.
- The global administrator accounts receive emails for all the transactions that are performed by Tachyon.
Different approaches for defining permissions
Tachyon provides a flexible system for defining permissions for the Tachyon features. There are a number of different ways of approaching the task, here we outline the general choices that can be made for assigning Tachyon users to system and custom roles.
Managing access primarily using the Tachyon Permissions console
In this approach the Tachyon users are added individually using their Active Directory credentials.
This approach is more secure than alternatives because all users, roles and access rights are managed only through the Tachyon Permissions console.
Managing access using Active Directory
Using this approach the Tachyon users are added as Active Directory security groups. The Tachyon roles are then associated with those groups and management of the individual users who can access Tachyon is subsequently done only through Active Directory. There are broadly three options when using this approach:
- A one-to-one approach where you create a Tachyon-specific role-based Active Directory group for each Tachyon role. For example you could create a TCNGApprovers Active Directory security group, and add that group as a user in Tachyon, and then assign the Tachyon Global Approvers role to the user.
- A many-to-one approach where you use one or more of your existing role-based Active Directory groups for each Tachyon role. For example you could use the Active Directory groups for your desktop and help desk teams, create a Tachyon user for each group, and then assign the Tachyon role to all those Tachyon users.
- A mixture of the above
It is possible for an Active Directory user to be associated with Tachyon roles for both running and approving actions. In practice this is safe because Tachyon prevents users from being able to directly approve their own actions regardless of the roles they have been assigned.
Defining a custom Instruction set Tachyon role
If you want to base your Tachyon permissions around access to specific Instruction sets you will need to create custom Tachyon roles.
To create a custom role:
- Navigate to the Settings→Permissions→Roles page.
- Click the Add button to start the add role process.
- In the Add role popup subsequently displayed set the Name and Description and click the Add button on the popup.
- The new role will be added to the Roles table. Locate its entry and click on the link in the Name column for that row to display the role's details page.
- With the Permissions tab selected click the Add button to display the Add permission popup.
- From the Type drop-down list select Instruction set - some new controls will be added to the popup.
- Select the required Instruction Set from the Name drop-down list.
- Set the Instruction set access rights by checking the required Actioner, Approver, Questioner and Viewer checkboxes.
- When the associated rights have been set click Add.
- The new custom role permission will then appear in the Permissions table.
- Before the new custom role can be used you must add a management group.
- Click on the Management groups tab.
- Click the Add button to display the Add management group popup.
- From the Select management group drop-down menu select the management group you want to associate the role with. This can either be the built-in All Devices or a management group you have created in Settings→Permissions→Management groups.
- Click the Add button to associate the selected management group with the custom role.
The following rights can be set for a Instruction set, these relate to the primary operator roles of the Tachyon system:
|Actioner||Able to run actions defined in the Instruction Set|
Able to approve actions defined in the Instruction Set for anyone other than self
If email is enabled, will receive an approval request email for each requested action in the Instruction Set
|Questioner||Able to ask questions defined in the Instruction Set|
|Viewer||Able to view responses to questions run from the Instruction Set|