Request: improve flexibility to integrate with CyberArk

[kgouldsk]

Can you please add support for environment variables (like those supported for ext applications) in the fields in connection properties?  It makes for much more flexible connection object creation.
 
We need this to work (this is easy for you to implement) – then we can copy connection objects and just rename them, and this parameter cascades down:


As an added “more flexible” solution that would support ad-hoc connections, also support something like this:


The (/prompt "Servername") would prompt the user with "Servername:" and would substitute the response in place of the parentheses section.

This would allow specification of a name when they connect – allowing multiple prompts would provide best flexibility.
 
While I’m shooting for the stars with requests, we have an issue of these connections pointing to a statically numbered “dynamic” proxy account.  If two people specify the same number on their connection, and attach to the same machine, the accounts will collide and the second one will be denied.  Support for the concept of a randomized number generated at connect time would reduce likelihood, as well as improving chances that a retry would use an unused account:
Proxyacct-DomA(Random(01-29))@mydomain.loc would translate to proxyacct-DomA15@mydomain.loc on an example connection request.  The smartest nomenclature for specifying this “random” token may not be as I’ve shown, you likely have better ideas.



We can work with option 1; option 2 allows ad-hoc, option 3 is pie in the sky and just reduces potential for account collision.

Will you please consider this?

[DevOma]

I added it to the feature list and we will see how and what we can implement in one of the next versions

[kgouldsk]

I added it to the feature list and we will see how and what we can implement in one of the next versions

Thank you!

[kgouldsk]

DevOMA, we are in production now with CyberArk - do you have any more detail on when we might see support for variables in the Executable Path field? Hand editing every connection object we create is arduous!

[DevOma]

Approx. 2 weeks

[kgouldsk]

Approx. 2 weeks

I continue to be dumbfounded by the rate at which you add requested features. Thank you so much. For most companies, it requires armies of customers badgering for version after version. So often, I see the request on the ASG-Remotedesktop forum and a release or two later, the feature is in. It's what makes the product so excellent - thanks from all of us.

[kgouldsk]

Hello, I see in the release notes that the new version should support variables in the Programs section of a connection object. 

I have tested it, and it works great - thank you!

Name: myhostname

Programs: psm /u epv01@domain.loc /a %Name% /c PSM-RDP


Now I'm able to define an object with the above parameter form, then just copy/paste/rename it multiple times to get objects for my individual servers.

[gp4ngd]

Currently, our team is using ASG 2018 Version 11.0.6169.1. Is this version compatible with integrating with CyberArk?

[DevOma]

I can't tell you in detail what is in that version and what we have added afterwards - you need to to test it yourself - I can just link to the following thread how other customers have integrated Cyberark into ASGRD and there are some requests we have added in the past

https://remotedesktop.rocketsoftware.com...?tid=11208

[Schristy]

Can you please add support for environment variables (like those supported for ext applications) in the fields in connection properties?  It makes for much more flexible connection object creation.
 
We need this to work (this is easy for you to implement) – then we can copy connection objects and just rename them, and this parameter cascades down:


As an added “more flexible” solution that would support ad-hoc connections, also support something like this:


The (/prompt "Servername") would prompt the user with "Servername:" and would substitute the response in place of the parentheses section.

This would allow specification of a name when they connect – allowing multiple prompts would provide best flexibility.
 
While I’m shooting for the stars with requests, we have an issue of these connections pointing to a statically numbered “dynamic” proxy account.  If two people specify the same number on their connection, and attach to the same machine, the accounts will collide and the second one will be denied.  Support for the concept of a randomized number generated at connect time would reduce likelihood, as well as improving chances that a retry would use an unused account:
Proxyacct-DomA(Random(01-29))@mydomain.loc would translate to proxyacct-DomA15@mydomain.loc on an example connection request.  The smartest nomenclature for specifying this “random” token may not be as I’ve shown, you likely have better ideas.



We can work with option 1; option 2 allows ad-hoc, option 3 is pie in the sky and just reduces potential for account collision.

Will you please consider this?

Hello can you please assist with Environment variables in case the ticketing is enabled with request number. What would be the parameter to input against the request number here?

 - psm /u <UserName> /a <DomainName> /c PSM-RDP /?? <requestNumber>

[DevOma]

Perhaps you should ask your question also on Cyberark support site - if there is a command line option it should be easy to inlcude