25-Sep-2020 04:55
04-Oct-2020 06:00
yes, the end-user can change some parameter.
others are signed and can't be changed, i.e.: Full Address,Server Port,GatewayHostname,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource
04-Oct-2020 22:59
Can you tell me please which kind of parameters can the user change?
Can you give me some examples?
Is there a KB for this one?
I tried in my 13.1.3.4 test environment to change the mapping sound parameter and got error when tried to connect
Thanks, I appreciate you help
10-Oct-2020 00:08
no K article i could find, as mentioned if you look in the RDP file you see what is signed, those parameters you can change.
as for the others it can also depend on what the server is supporting or allowing to be change i assume.
what error did you get?
also you might want to check if that issue remains with the 14 release.
10-Oct-2020
01:37
- last edited on
05-Jun-2023
23:04
by
JimmyPackets
Hi
I see those configuration lines in my downloaded RDP file:
audiomode:i:1
authentication level:i:0
enablecredsspsupport:i:0
full address:s:172.24.2.3
gatewayaccesstoken:s:diOG_Pn7Ysseob....
gatewaycredentialssource:i:5
gatewayhostname:s:my.domain.com
gatewayprofileusagemethod:i:1
gatewayusagemethod:i:1
server port:i:3389
signature:s:AQABAAEAAABFCAAAMIIIQQYJKoZIhvcNAQcCoIIIMjCCCC4CAQEgggggggMAsGCSqGSIb3DQEHAaCCBnIwggZuMIIFVqADAgECAhAP......
signscope:s:Full Address,Server Port,EnableCredSspSupport,GatewayHostname,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,Authentication Level,AudioMode
If I for example delete the first line: audiomode:i:1 I will get an error
Again, which I think this is good for security, And for not starting with configuring GPO settings in customer internal servers..
This error I'm getting:
Also, if I delete the "signscope" line and delete the audio mapping line and replaced it with, for example, drivestoredirect parameter then I get:
But if I delete the "signscope" line then I can delete the configured parameters.. like the audio mapping parameter.. and RDP will still work... which is not that bad for me .. eventually the user currupted the file and it is his fault.
But I don't want in any case the user be able to replace parameters with his..
If it is not the same behavior with v14, then this bad.. why would f5 change this behavior in v14 ?
unfortunatlly I don't have f5 running v14 to test it, but I heard from other people running this version that they managed to change the RDP parameters if they delete the "signscope" line and still be able to connect.
Is is possible to enforce user not to change anything is the native RDP file ?
10-Oct-2020 01:56
interesting, never tested this that far.
i dont have an answer to this and can't find any documentation on it, if no one else replies in the next few days i suggest to open a F5 support ticket to discuss this.
10-Oct-2020 02:08
I edited my answer.. I ran further tests ... check it 🙂
anyway, I will ask f5 support team..
Thanks
13-Oct-2020 22:10
F5 support answer:
"The only thing the APM checks when the RDP connection request comes back in are the APM session cookie, and the gateway access token.
We cannot check and enforce other RDP parameters, because if the APM session cookie and the RDP gateway access token is valid then APM establish a websocket between the RDP client and Terminal Server. At that stage it depends on the Terminal server to enforce the RDP settings."