Delinea Secret Server

Hello,
I am able to get RDM to integrate with Secret Server without 2FA enabled on Secret Server. When I enable 2FA (just the built in OTP) it fails with "unknown error". Any help would be appreciated.

Thanks,
Ben

@benyancey,

2FA on Secret Server is not supported in RDM for the moment and this is why it's not working when you enable it.

Our integration needs to be updated and it's on our roadmap to do it soon. I don't have an ETA, but we will post on the forum when it will be available.

Best regards,

Hello,

im not sure if this is a bug report or a feature request.
We have the issue that RDM disregards the port of a connection if its using a proxied connection over delinea Secret Server.
so whatever port we specify here, in this case 3001, is disregarded and it always uses the standard 22.

This on the other hand works directly in SecretServer



Would it be possible to fix/add this to RDM?

Best regards,
David

We are using Delinea Secret Server with PAM Distributed Engines for multiple sites.
I'm not managing this part, but I'm in charge of RDM RDP Sessions (so Windows only) and their linked credentials.

With this config in RDM 2026, the proxy connection and its associated port is not managed inside RDM RDP Session, but at Delinea Secret credential side, setting the PAM DE site and enabling the proxy option at secret level.

Ex : Secret existing in Delinea Secret Server :


The only thing I have to do at RDM side, is to set the "Connection through proxy" resolving mode on RDM Delinea Secret Server Credential linked on the RDM RDP Session.

Ex : Delinea Secret Server Credential created in RDM :


Don't know if it can help in your case.

Kr.

Hi David,

Thanks for the clear write-up and screenshots — that comparison between the RDM entry and the Secret Server launcher is exactly what pinned this down. And thank you to Olivier as well; his setup points at the right approach here.

The key detail is in your two screenshots. In RDM, the SSH entry keeps Host and Port as two separate fields (test.something and 3001), whereas Secret Server's own proxied launcher takes the target as a single string — test.something:3001 — with the port riding inside the host value. When RDM hands the session off to the Delinea proxy, the target endpoint (including the port) is resolved on the Delinea side rather than from RDM's Port field, and in this proxied path the separate Port value isn't being carried through — so the proxy falls back to its SSH default of 22. Your own test is the proof that the proxy itself can absolutely reach 3001; it's just a matter of getting that port to the proxy from RDM.

There are two ways to get there. The most robust one is what Olivier described: store the target machine and its port on the Delinea Secret and enable the proxy at the Secret level, then set the credential's resolving mode to "Connection through proxy" in RDM. That way the port lives where the proxied flow expects to resolve it, and RDM doesn't need to pass it at all. If you'd rather not restructure things, it's also worth a quick test to put test.something:3001 directly in RDM's Host field and leave the Port at its default — that mirrors exactly what works in the Secret Server launcher. I'd treat that second one as a "try it and see," since I haven't confirmed how RDM parses a host:port string in that field.

To make sure I'm advising on the right configuration, could you let me know: is this entry a standalone SSH session linked to a Delinea credential, or a Secret-linked entry? And which RDM version are you on? There's been recent work in this area — a new "hybrid" resolving mode shipped in 2026.2.8 — so the version matters.

On the bug-vs-feature question you raised: it sits in a bit of a grey area. In proxy mode the endpoint is meant to be resolved on the Delinea side, so one could argue RDM ignoring its own Port field is consistent. But RDM does show you a Port field that silently does nothing when proxied, and I think that's worth a closer look on our end. Once you confirm the version and entry type, I'll take the "Port field ignored on proxied connections" behaviour back to the team for review.

Talk soon,