Support server-side credential validation (e.g. PAM) via CredentialValidator trait

[glamberson]

Summary

IronRDP's current credential model assumes pre-loaded credentials (exact match at acceptor level). This works perfectly for credential-injection architectures like Devolutions Gateway, but makes it impossible for standalone RDP servers to implement server-side validation (PAM, LDAP, database-backed auth, etc.).

I'd like to propose a CredentialValidator trait that would enable both use cases cleanly.

Current Architecture

The Acceptor receives credentials from the client in ClientInfoPdu during SecureSettingsExchange and compares them against pre-loaded server credentials:

// connection.rs:554-569
if !protocol.intersects(SecurityProtocol::HYBRID | SecurityProtocol::HYBRID_EX) {
    let creds = client_info.client_info.credentials;
    if self.creds.as_ref() != Some(&creds) {
        return Err(ConnectorError::general("invalid credentials"));
    }
}

This has two limitations for servers that need to validate credentials on receipt:

1. No validation hook: The acceptor either matches exactly or rejects. There's no way to intercept the credentials and validate them against an external system (PAM, LDAP, etc.).

2. Credentials not exposed after handshake: AcceptorResult doesn't include the received credentials. They're extracted at line 555 and dropped after comparison, so even with fix(acceptor): skip credential check when server credentials are None #1150 (skip check when None), the server has no way to retrieve what the client sent for post-handshake validation.

Use Case: Standalone Linux RDP Server

I'm building lamco-rdp-server, a standalone Linux RDP server using IronRDP. For Linux servers, authentication against system accounts via PAM (pam_authenticate) is essential. The flow should be:

1. Client connects over TLS
2. Client sends credentials in ClientInfoPdu
3. Server extracts credentials and validates via PAM
4. Server accepts or rejects the connection

This is the same flow that xrdp uses for PAM authentication. It requires TLS-only mode (not CredSSP/Hybrid) because PAM validates credentials, whereas CredSSP/NTLM requires the server to already know the password.

Why This Doesn't Apply to CredSSP

I understand that the current model is by design for Devolutions' architecture: the Gateway pre-loads credentials from its vault and injects them via CredSSP. CredSSP fundamentally requires pre-known credentials for NTLM challenge-response. The proposed trait wouldn't change CredSSP behavior at all.

Proposed Solution: CredentialValidator Trait

/// Server-side credential validator for TLS-mode connections.
///
/// Called during SecureSettingsExchange when the server receives
/// client credentials via ClientInfoPdu. Not used for CredSSP/Hybrid
/// connections (those use pre-loaded credentials for NTLM).
pub trait CredentialValidator: Send + Sync {
    /// Validate credentials received from the client.
    /// Return Ok(true) to accept, Ok(false) to reject.
    fn validate(&self, credentials: &Credentials) -> Result<bool, ConnectorError>;
}

The Acceptor would accept Option<Arc<dyn CredentialValidator>>:

• None: No credential check (equivalent to current creds: None with fix(acceptor): skip credential check when server credentials are None #1150 merged)
• Some(validator): Call validator.validate(&creds) during SecureSettingsExchange

Built-in implementations for backward compatibility:

/// Exact match against pre-loaded credentials (current behavior)
pub struct ExactMatchValidator(Credentials);

impl CredentialValidator for ExactMatchValidator {
    fn validate(&self, creds: &Credentials) -> Result<bool, ConnectorError> {
        Ok(&self.0 == creds)
    }
}

/// Accept all credentials (for no-auth servers)
pub struct AcceptAllValidator;

impl CredentialValidator for AcceptAllValidator {
    fn validate(&self, _: &Credentials) -> Result<bool, ConnectorError> {
        Ok(true)
    }
}

This follows the pattern used by rustls (Arc<dyn ServerCertVerifier>) and tonic interceptors.

Interim Solution

While this trait is designed and reviewed, I'll submit a small companion PR to #1150 that adds the received credentials to AcceptorResult. This is a minimal, non-breaking change that enables post-handshake validation as a stopgap:

pub struct AcceptorResult {
    pub static_channels: StaticChannelSet,
    pub capabilities: Vec<CapabilitySet>,
    pub input_events: Vec<Vec<u8>>,
    pub user_channel_id: u16,
    pub io_channel_id: u16,
    pub reactivation: bool,
    pub credentials: Option<Credentials>,  // NEW
}

This stopgap would be superseded by the trait approach once it lands.

Impact Assessment

• Devolutions Gateway: No impact. Gateway uses CredSSP with pre-loaded credentials, which bypasses SecureSettingsExchange credential handling entirely.
• Devolutions Agent: No impact. Agent doesn't set credentials and doesn't use TLS-mode credential validation.
• Existing API: Backward compatible. ExactMatchValidator provides the same behavior as current Some(creds). The set_credentials(Option<Credentials>) API could be preserved as a convenience method that wraps into ExactMatchValidator.

Related

• Acceptor rejects TLS connections when server credentials are None #1149 / fix(acceptor): skip credential check when server credentials are None #1150: Skip credential check when None (prerequisite, already submitted)
• How can I check RDP credentials? #508: "How can I check RDP credentials?" (previous user with similar need)

[glamberson]

Update: PR #1155 (expose credentials in AcceptorResult) merged. Thanks for the quick review on that one.

PR #1150 is rebased and CI-green. Benoît Cortier (@CBenoit), your feedback on #1150 about wanting explicit opt-in for no-auth is exactly what this trait addresses. The design here ensures that:

• No validator configured + no credentials = reject (safe default, prevents accidental no-auth)
• ExactMatchValidator(creds) = current exact-match behavior
• An explicit AcceptAllValidator is required to enable no-auth

So the trait makes the current security posture more explicit rather than loosening it.

I anticipate submitting the PR once #1150 lands.

Thanks.