Product Ideas Portal

Got an idea for a new feature? Maybe a tweak to make something work even better? Wish there was an integration with another product to make you even more productive? You've come to the right place.

The Product Ideas Portal lets you submit whatever product feedback you have, good, bad, ugly, and anywhere between.

Want to stay anonymous? Don't worry, no email address or name fields are shared on the public portal. You can create an account which lets you vote on other people's ideas and receive updates when your idea's status changes.

To learn more about how an idea becomes a feature, check out this infographic.


Display Password Comment Instead of Credential

AFAIC, there is a fundamental shortfall in the way 'available credentials' are listed when attempting injection on an endpoint.

The desired behaviour would be that only the related credentials would be listed, rather than the full list of those that the operator has permission to inject.

To my mind, a sensible logic function should be added at the point of processing / creating the dropdown list to show only matching credentials where the domain suffix (i.e. the string before the '\' delimiter) in the credential matches the domain on the target machine.

This logic would only work against domain devices, but would provide a significant reduction in the visible noise when there are thousands of listed credentials, many very similar.

Given this, the easiest approach (and surely the easiest to implement) would be to display the credential Comment attribute instead of the username;

i.e.
- Import a credential (domainA\user) with a password comment of "Business A Admin"
- Import a credential (domainB\user) with a password comment of "Business B Admin"

The backend functions / links to objects themselves should not need to be addressed, but when the injection list is rendered it displays the associated comments ("Business A Admin" and "Business B Admin") instead of the credential itself.

Where there is no password comment; display the credential. This change would allow existing instances who don't have the comment attribute defined to continue as they are working, but would allow estates such as ours the ability to easily see the appropriate credentials to be utilised.

...Of course if a filter was added to this as well, the solution would be absolutely perfect.

  • Guest
  • Jan 31 2020
  • Future consideration
  • Attach files
  • Guest commented
    3 Mar, 2020 11:48am

    For those who may stumble upon this; the actual issue is that the 'hostDomain' attribute is NOT sent by the PRA appliance to the ECM front-end.

    This has been confirmed by BeyondTrust to be a bug in PRA which will be patched in a later revision.

    I can confirm the test patches work flawlessly.

  • Guest commented
    31 Jan, 2020 02:26pm

    A further alternative to this would be for the Jump Clients to check-in with their FDQN as the 'hostname' as PAM / PRA sees it.

    Context; if you test for valid credentials available for a delegate via ECM directly using the FDQN of the device... it returns only the appropriate credentials.

    If you test against the hostname alone, all available 'domain' credentials are presented.

    This appears to be a bug more than a 'new idea'...

  • Guest commented
    31 Jan, 2020 11:23am

    This is a major flaw in the product when considering in either an MSP environment and indeed large client estate where multiple credentials are available to a user, which reduces significantly the benefit of this feature, in short, making the current solution far less valuable to our organisation! Please can you determine any potential ETA for this dev.