tab page title on CyberArk PSM Connection not working ?
Hi,
We are trying to modify the tab page title filed using variables on CyberArk PSM Connection.
Unfortunately it doesn't work. Nothing is taken into account
It works on RDP connection for instance.
Do you know if it has been fixed on last versions ?
We are currently using 2019.1.38 build.
All Comments (5)
Hello,
We will take a look and get back to you. I think the issue is still there on our latest release, and if that's the case, we'll open a ticket to work on it.
Regards,
Hubert Mireault
Hello,
The variables must be "consumed" in the template.
The sequence of events is
- We take a copy of the template,
- Overimpose the host&credential information from the PSM Server entry onto the template copy
- lasttly, we create the alternate shell command using the PSM Connection Entry.
The 4 fields of the PSM Connection will not be available, but everything else should return valid data if its defined in the template.
What have you tried?
Maurice
Bonjour Maurice,
We tried to modify the tab page title (on user interface menu) on our CyberArk PSM Server entry and also on the RDP template called by the CyberArk PSM Server entry.
What we identify is :
- On CyberArk PSM Server : adding chaintext or variable on tab page title didn't change anything on the fianl connection
- On RDP Template : adding "jaimelesfleurs" is working but adding $NAME$ (the target we wouldlike to use) didn't work.
At the end we would like $NAME$ in the tab (it's the server's name) instead of a very long host by default.
Bonjour,
So at the end, if I understand well, the RDP template must contains somewhere the server name as a variable.
But because it's a template, there is nothing else than the host with a very long fqdn name :
In our case : Host = $NAME$-mgmt.jaime.les.fleurs.net
And we would like to have only $NAME$ as tab.
Is there a way to SPIT an chain text value for instance ?
Hello,
We do not have string manipulation routines for our fields at this time.
I guess we could ask for a new variable to be created that would extract the host name from a FQDN, but its touchy because we already call that field HOST. (10 years ago when RDM was started the notion of a FQDN was not really widespread...) We'll try to come up with a name that's not too confusing
I will talk to the engineer in charge, but it will have to wait until the week of January 4th. I am setting myself a reminder to update this topic at that time.
Best regards,
Maurice
