Info: Updates to Groups and Work functionality (beginning with Trust Protection Platform 17.2)

Applies To:

Trust Protection Platform 17.2 through 17.4, and Trust Protection Platform 18.x


17.2 Brings updates to the configuration of groups and work for Server Agents, Enterprise Mobility Agents, SSH Agentless Groups, and for the User Portal.  If you are currently using any of these features, it is important to understand what the changes are, how they might affect your production usage features, and what you may need to do to have a successful upgrade to 17.2 or higher.

Note: When upgrading to 17.2, your work list may be significantly longer than expected.  It is a combination all works created for all groups prior to 17.2

Reason for the changes:

The User Interface in Aperture was primarily designed in 14.1 for managing groups work for the purposes of Server Agents.  Since then the use cases have grown so that this area of the UI is also used to manage Enterprise Mobility Agents, the End User Portal, and work for managing SSH keys using agentless technology.

These updates make it easier to configure groups and work for different use cases by preventing invalid configuration options and being able to reuse the same Work across one or more groups. It also allows for easier and more precise delegation to others within the organization.

What's Changed:

Top Navigation Changed

"Agents" top navigation was changed to "Groups & Work".  The "Agents list" was renamed to "Registered Clients".  Agent Registration was moved from "Configuration" over to "Groups & Work" menu grouping.

Separation from Groups and Work

From 14.1-17.1, works could only be accessed after creating an group.  Now they are created, managed separately, and assigned to groups.  One work can be assigned to multiple groups if needed.  When using the User Portal or Enterprise Mobility Agents, you can now assign multiple User Certificate Creation work types to the same group, something not possible in previous versions.

3 "Group types"

In past versions you could choose either "Agent installed" or "no Agent installed".  The "no Agent installed" use case was only really used for "SSH Agentless" work of discovery and remediation.  While "Agent installed" was used for everything else.

In 17.2 the use cases have been expanded and clarified, so that all groups must have a type.  If your group was "No Agent Installed" then when you upgrade your group type will change to "Agentless SSH Key Management".  If your group type was "Agent installed" then your group type will change to "Agent-based Certificate and Key Management".

Important Note: If you had a "Agent installed" group but were using it for issuing user or device certificates, you will need to change your group type to "User and Device Certificate Issuance" after upgrading in order for it to continue to function properly.


Membership criteria that is responsive to the type of group

While in past versions there was some differences in membership criteria between "Agent installed" and "no agent installed" group types the product has been enhanced so that rule types and values are only available if they are applicable to your specified group type.  For example, there is a rule type called "Member of" that is used to specify Active Directory or LDAP groups you want users to be a member of in order to have User Certificates issued to them.  In 17.2 this rule type is only available to the group type  "User and Device Certificate Issuance".

Membership criteria requires a Client Type rule

All groups require the first rule to be a "Client Type" rule.  This is to ensure that the group only applies to the clients that it was intended to work with.  If you are creating a new group this rule will be automatically created for you, but if you have an existing group that you are upgrading, you may get an error when you review the membership criteria prompting you to either set the appropriate group type, or fix your membership rules for what is required for a group.  If needed, you can view the "Raw Rule String" for what is currently saved to aid in updating the membership criteria for what is enforced to be required in 17.2.

Work assignments that are responsive to the type of group

 In past versions it was possible to assign a "Certificate Discovery" work type to a group intended for Agentless SSH Key Management.  New in 17.2 is that the product will only allow you to add work types that are appropriate for your group.  It also enforces a quantity check.  What this means is that if you have a group for "User and Device Certificate Issuance" it will only allow one "Agent Connectivity" type of work to be assigned, but it will allow as many "User Certificate Creation" work types as you need.

Groups and Work Names

In previous versions, work was given a name automatically and groups could never be renamed. In 17.2, groups can be renamed using the same method used to rename other items in Aperture, by hovering over the name in the title bar so that the pencil appears.  Rename permissions are required to use this feature.  Also new to 17.2 is that work can be given a custom descriptive name when created.

More granular permission control

In previous versions, when assigning permissions to work, you had to give a user either permission to all of the work assigned to a group or none of it, there wasn't a way to assign permissions that were specific to only one work item.  Now in 17.2, if you want to delete permissions to an individual so that they can only manage the a certificate discovery work, you can, without giving them permissions to anything else within Groups & Work.

What to check on Upgrade:

  • If using the User Portal or Enterprise Mobility Agent, you will need to change the group type to "User and Device Certificate Issuance"
  • If using the User Portal or Enterprise Mobility Agent, you will want to review your membership criteria to ensure all of your rules meeting current requirements.  If there are any problems, fix them.
  • If you are using the automatic disable or revoke feature for "User Certificate Creation" type work, you will want to review the group membership settings that Venafi uses to monitor for group membership. In past versions was a feature that allows the work to be linked to the membership criteria of the group, this feature is removed and you must specify the group you want to monitor explicitly on the work.  Please review these settings on upgrade.
  • In previous versions, the Work Names were automatically generated, but were placed in a folder based on the name of the group the work was assigned to.  You may find it easier if you review the folder name for different work that you have enabled and give them a custom name that is more meaningful to your organization.
  • You may want to review the work assignments of your group to make sure there are not any assignments that are not compatible with your group type.  Once you remove incompatible work types, you will not be able to re-add them.  For example, if you have "Certificate Discovery" assigned to a group designated for "Agentless SSH Key Management", you should remove it.
Was this article helpful?
1 out of 1 found this helpful