Hello everyone, I’m fairly new to the community and have been reading through the discussions here for a few weeks before deciding to post. I’ve been tasked with evaluating and troubleshooting our Privileged Access Management setup, which involves Delinea Secret Server (on-premises, version 2023.5) and Duo for MFA. I’ve run into a persistent issue that I haven’t seen fully addressed in the existing threads or documentation, so I’m hoping for some guidance.
Our configuration uses the Delinea proxy to handle connections for a set of Windows servers. The Duo integration is set up and works correctly for direct logins to the Secret Server web portal—users receive a push notification to their Duo Mobile app and can authenticate successfully. However, when users attempt to connect through the proxy (using the Launcher or direct RDP/SSH connections configured within Secret Server), the MFA push is not triggered. The connection either fails after the primary credentials are accepted or times out waiting for the secondary authentication. The proxy logs indicate the authentication request reaches the proxy, but there’s no subsequent handoff to Duo.
I have verified the following details so far:
- The Duo application key, integration key, and secret key are correctly entered in the Secret Server Duo configuration.
- The proxy servers can reach both our Duo security gateway and the Duo API endpoints over the network; there are no firewall blocks on the necessary ports.
- The user accounts in Secret Server have Duo enabled and are mapped correctly to their Duo usernames.
- The proxy configuration file appears standard, with the MFA provider set to Duo.
Given my background in ERP and inventory systems, I’m accustomed to methodically tracing integration points, but I’m less familiar with the internal flow between the Delinea proxy and an external MFA provider. Has anyone encountered a scenario where Duo pushes work for the web UI but fail specifically for proxy-mediated sessions? I’m particularly interested in whether there are known requirements for the proxy host itself to be registered as a Duo application separately, or if there are specific callback or timeout settings within the proxy configuration that need adjustment for Duo. Any insight into log locations on the proxy side that might show more granular detail about the MFA handoff failure would also be extremely helpful.
The classic split-brain authentication scenario. You've confirmed the proxy sees the initial request, which means the issue is almost certainly in the handoff between the proxy agent and the Secret Server's Duo integration service. The proxy operates at a network session layer, while the Duo integration typically hooks into the Secret Server's web authentication pipeline.
First, check the Secret Server logs for the Duo Auth API module (usually `DuoAuthenticationProvider.log` or similar) during a proxy connection attempt. You'll likely see no entry, confirming the disconnect. The proxy's authentication flow is probably defaulting to a failback method or hitting a timeout because the callback URL or session context isn't being propagated correctly from the proxy's subnet.
A common misstep is the Duo application's "Allowed host" configuration. It needs to include the proxy server's source IP addresses, not just the Secret Server's web front-end. The proxy originates the MFA request from its own IP, and if that's not whitelisted, Duo silently drops it.
Measure twice, cut once.