Skip to content

feat(dgw): route KDC traffic through agent tunnel (DGW-384)#1781

Open
irvingouj@Devolutions (irvingoujAtDevolution) wants to merge 1 commit into
masterfrom
feat/DGW-384-kdc-agent-tunnel
Open

feat(dgw): route KDC traffic through agent tunnel (DGW-384)#1781
irvingouj@Devolutions (irvingoujAtDevolution) wants to merge 1 commit into
masterfrom
feat/DGW-384-kdc-agent-tunnel

Conversation

@irvingoujAtDevolution
Copy link
Copy Markdown
Contributor

@irvingoujAtDevolution irvingouj@Devolutions (irvingoujAtDevolution) commented May 12, 2026

Closes DGW-384.

Routes KDC traffic through the agent tunnel for the two remaining paths after #1741:

  • HTTP /jet/KdcProxy endpoint
  • RDP CredSSP/NLA (rdp_proxy.rs::send_network_request)

send_krb_message gains (agent_tunnel_handle, session_id: Uuid). RDP callers pass claims.jet_aid so agent-side logs correlate KDC sub-traffic with the parent RDP session; the HTTP handler mints a fresh UUID since its token has no parent association.

Depends on #1741 — must merge first (uses agent_tunnel::routing::try_route).

@github-actions
Copy link
Copy Markdown

Let maintainers know that an action is required on their side

  • Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

  • Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

  • Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

  • Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries

When an agent advertises the KDC's subnet or DNS domain, route Kerberos
traffic through the QUIC tunnel just like every other proxy path. This
closes the last gap left after the transparent routing PR (#1741):

- `/jet/KdcProxy` HTTP endpoint — `send_krb_message` now consults the
  routing pipeline before falling back to direct TCP. The HTTP handler
  has no parent association, so it mints a fresh session_id purely for
  agent-side log correlation.

- RDP CredSSP/NLA — `rdp_proxy.rs::send_network_request` previously
  hard-coded `None` for the agent handle. Plumb `agent_tunnel_handle`
  and `session_id` from `RdpProxy` down through `perform_credssp_with_*`
  → `resolve_*_generator` → `send_network_request`. The same change
  reaches the credential-injection clean path (`rd_clean_path.rs`).
  `session_id` here is `session_info.id` / `claims.jet_aid` so the
  agent log ties KDC sub-traffic to its parent RDP session.

Stack: based on #1741. Picks up `agent_tunnel::routing::try_route`.

`send_krb_message` signature gains `(agent_tunnel_handle, session_id)`
in that order — required `Uuid`, no `Option<>` — so the call site is
honest about which UUID it's logging. The UDP scheme guard (KDC over
UDP keeps going direct because the agent protocol only carries TCP)
and the 64 KiB `MAX_KDC_REPLY_MESSAGE_LEN` DoS cap (and the matching
generic `read_kdc_reply_message`) come along since they live in the
same file and serve the same end.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant