Forum Discussion

The-messenger's avatar
The-messenger
Icon for Cirrostratus rankCirrostratus
Jul 27, 2016

iRule for RDS Session

I'm a newby at this so forgive me in advance if that applies. I'm running iapp rds_session_host.v10.2, I would like to use Big-IP to route RPD traffic to assigned desktops, based on user name.

 

Looking to keep this RDP not HTTPS, userA, userB open Remote Desktop and login, Big-IP routes userA to RD-Machine-A, routes userB to RD-Machine-B.

 

Is this possible?

 

application delivery
BIG-IP
iRules

1 Reply

Sort By
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jul 29, 2016

    Hi kfoutts@polsinelli.com,

    The RDP Protocol has indeed a build-in support to pass the username (aka. the "MSTSHash Cookie") to support load balancing decissions. But this functionality is unfortunately "somewhat" problematic to use, since...

    • The username field of the MSTSHash Cookie will be truncated to the first nine characters (including DOMAIN\ notations)
    • Its somewhat unreliable, because of certain client side flaws/bugs, causing the the Microsoft RDP client to not update the cookie value on username changes or sometimes doesn't even send the username at all.
    • Its again somewhat unreliable, since not every 3rd party RDP client do support the "mstshash cookie" mechanism.

    You could evaluate the "MSTSHash Cookie" functionality by using the iRule below. The iRule will [TCP::collect] the first RDP packet, extract the username from the "MSTSHash Cookie" field and then simply 

    [log]
    the the value to your LTM logfile. 

    when CLIENT_ACCEPTED {
    TCP::collect
}
when CLIENT_DATA {
    if { [TCP::payload] contains "Cookie" } then {
        log -noname local0.debug "RDP Session provides the Cookie = [findstr [TCP::payload] "Cookie: " 8 "\n"]"
    } else {
        log -noname local0.debug "RDP Session does not provide a Cookie"
    }
    TCP::release
}

    Note: The provided iRule could be easily extended to lookup a datagroup to select a RDP host for a given username. But again, I highly doubt that the "MSTSHash Cookie" functionality is stable enough, to meet your requirements.

    Note2: Parsing the "MSTSHash Cookie" will be most likely the only possibility you have, to inspect the username and route the session to a given terminal server. If this functionality won't meet your requirements, then it MAY be possible to intercept/relay the X.224 BPDUs (its easy) of the initial RDP handshake, proxy/insepct the TLS negotiation of the RDP protocol (little more complicated) and then parse the NTLM challange/response of the RDP network level authentication (I never did that before)...

    Cheers, Kai