* TS_GENERAL_CAPABILITYSET::protocolVersion must be
TS_CAPS_PROTOCOLVERSION(0x200) see [MS-RDPBCGR] 2.2.7.1.1
General Capability Set (TS_GENERAL_CAPABILITYSET)
* Default value of FreeRDP_CapsProtocolVersion must be
TS_CAPS_PROTOCOLVERSION(0x200)
Split settings, there was a double use for AutoReconnectEnabled.
AutoReconnectEnabled is a setting responsible for client side
autoreconnection.
AutoReconnectPacketSupported is a flag set by the server to announce
support for AutoReconnectPacket allowing fast reconnect.
* use dynamic logger in RDG
* honor [MS-TSGU] 2.2.9.2.1.5.2 TSG_REDIRECTION_FLAGS
* honor [MS-TSGU] 2.2.10.16 HTTP_TUNNEL_AUTH_RESPONSE
HTTP_TUNNEL_AUTH_RESPONSE_FIELD_REDIR_FLAGS flag
* add setting GatewayIgnoreRedirectionPolicy to ignore the gateway
policy if desired
the function uses implicit color formats. Replace this with the function
shadow_subsystem_pointer_convert_alpha_pointer_data_to_format with
explicit source color format.
Deprecate the old function.
shadow_capture_compare_with_format and shadow_capture_compare always
operate on distinct memory areas. Allow better optimization of
operations with the WINPR_RESTRICT keyword
To support legacy targets add the TlsSecLevel configuration option that
is equivalent to the /tls:seclevel option of the client implementations.
This allows automatic configuration of OpenSSL legacy providers if they
are available.
The previous code was assuming that the host name used for doing AAD was
ServerHostname parameter. But when you connect directly to Azure hosts you most
likely connect by IP and use short name for the AAD host, so you need to be able
to give ServerHostname=<IP of host> and AadServerHostname=<shortname>.
* use enum types for settings getter/setter to have compiler check if
keys are valid
* generate enum types from struct at compile time
* CMake option WITH_OPAQUE_SETTINGS to hide rdpStruct implementation
from external projects
Adds support for server-side remote credential guard in NLA. When enabled that allows
the remote user to connect without shipping credentials in TSCred packets. Instead
it will send his TGT encoded with a TGS from the remote server. This way the server
is able to populate that TGT in a local credential cache without knowing the user's
password.
The patch only treats the NLA part and does not contain the associated RDPEAR channel
that allows to have the complete interaction to retrieve new access tokens.
freerdp_client_settings_parse_command_line_arguments_ex allows supplying
user defined options to be parsed with the default ones from
client/common.
A callback must be implemented to handle the supplied arguments.
The mouse cursor channel enables remoting of the mouse cursor (bitmap)
over a DVC. The main use case is UDP, as only virtual channels can be
transported via UDP in RDP.
With the location channel, an RDP server can redirect the location of
the user from the client side to the server side.
The PDUs are almost the same as in the documentation, except for the
encoded types, these ones are here already parsed.
Optional values are accessed via pointers. If the pointer of a value is
NULL, then that value was not supplied by the client side.
Some virtual channels, like the location channel use encoded types to
lower the bandwidth usage.
Add common helper functions, so that each virtual channel doesn't have
to reimplement the parser functions again and again.
Under windows you can connect to a child session by requesting a named pipe to
the local server, and then do some RDP on this named pipe.
The protocol is like for /vmconnect with CredSSP, then Nego and then the "normal"
workflow for a connection. For CredSSP we force the usage of NTLM for the Negociate
SSPI, and the credentials are empty.
This patch moves the ARM configuration before starting the connection process, so
that we can do some provisioning of the FreeRDP settings with the items retrieved
from Azure.
Most notably that allows us to connect directly using RDSTLS security.
Some windows APIs do put \r\n every 64 characters of the output of a
base64 encoded blob. The extended version of crypto_base64_encode allows
to do the same.
C requires prototypes or compilers will complain about them missing. Our
library entry points do not have such, therefore add the macro
FREERDP_ENTRY_POINT which declares the function prototype automatically
before the function.
All clients can implement their own callbacks for
certificate/credential/smartcard/... but there is a common (default)
implementation for all clients.
with the new setting FreeRDP_UseCommonStdioCallbacks it is now possible
to force these over the client implementation provided ones
The AAD and AVD authentication mechanisms both need an OAuth2 token.
They only differ in the provided arguments, so unify the callbacks into
a single one with variable argument lists.
- Move responsibility for obtaining access tokens to clients
- Add function for getting access tokens for AVD
- Get correct server hostname during AVD setup
- Add utility function for doing http requests
The purpose of clipboard data locking is to make the other peer
retaining the current file list until a pending paste operation is done,
even though the clipboard selection changed.
As it may be difficult to determine, when a lock is needed, imitate the
same behaviour as mstsc:
When the server side supports clipboard data locking, always attempt to
lock the file list on the server regardless of what is advertised in a
FormatList PDU.
The Lock Clipboard Data PDU can even be already sent, before the
Format List Response PDU is sent.
This is also what mstsc, does: First, lock the new (potential) file
list, then unlock the file list, when the pending paste operation is
done.
So, rework the current clipboard implementation in that direction.
Since the implementation for timeouts for old file lists is a bit hard,
for now always force unlock pending locks, when the selection changes.
However, timeouts for old file lists can still be added in the future.
The reworked clipboard handling is done with the help of three hash
tables:
1. The inode table: This hash table manages all inodes for each file.
The keys in this table are the inodes themselves, while the values
the files and directories and their attributes (file size, last write
time, etc.).
2. The clipdata table: This table manages the locks for each file list.
The keys in this table represent the clip data id and the values the
clip data entries, which have a reference to the clip data dir, a
directory containing the whole selection, and some helper attributes,
like the clip data id itself.
3. The request table: Every file size or file range request is managed
here. When a FileContentsRequest is made, its stream id with the
respective details are added to this table. When a response is
received, these details can then be easily looked up here.
akallabeth