This patch implements the client-side part of the remote credential guard feature
as described in MS-RDPEAR. The 2 main changes are: shipping the TSRemoteGuardaCreds in
NLA, and implement the rdpear channel that allows LSASS to remote all the calls to
our client. For now it's UNIX only as the windows implementation would be implemented
in a completely different way.
To test, you may establish you ccache and then connect with (RCG enabled on the server):
xfreerdp /remoteGuard /u:<user> /d:<domain> /v<server>
That should log you in, and in the session you should not be asked for credentials when
doing mstsc /remoteGuard /v:<other server>.
Add the wrapper function utils_reload_channels that unifies the channel
cleanup and channel initialization sequence required on connect,
redirect and gateway policy apply
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.
update initial state transitions according to [MS-RDPBCGR]
the diagram is misleading, some of the text below ambigious, but
1.3.1.1 Connection Sequence phase 10 description lists the dependencies
of server initiated messages.
On some platforms (i.e. Mac) the BOOL type might be narrower than the
`RedirectionFlags` type leading to an overflow when just assigning the
logical AND result to the setting. This fix makes sure that the value is
correctly set to either `TRUE` or `FALSE`.
contrary to '[MS-RDPBCGR] 1.3.9 Connect-Time and Continuous Network
Characteristics Detection' we have seen autodetection reqeusts mixed in
between licensing messages. This relaxes the state machine and allows
handling.
Server side we often see "FreeRDP_ChannelDefArray::len expected to be >= 31,
but have XXX", where XXX is lower than 31.
This patche fixes that, the old code was setting the size of ChannelDefArray to the
number of ChannelCount, which is usually not what we want. We want to keep it to 31
and have ChannelCount indicate how many of these channels are used.
Currently, FreeRDP-based server implementations can do connect-time
autodetection.
However, without having any control over it.
In order to be able to override the default connect-time autodetection
handling, introduce three new states for the state machine of the
connection sequence and two new callbacks for the autodetect handling.
These are:
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_BEGIN
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_IN_PROGRESS
- CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_END
- OnConnectTimeAutoDetectBegin()
- OnConnectTimeAutoDetectProgress()
The END state is pretty simple: When the autodetection is finished and
the autodetect state is FREERDP_AUTODETECT_STATE_COMPLETE, transition
into the next state of the connection sequence.
The BEGIN state is entered, when capability-wise network autodetection
is available.
In this state, the OnConnectTimeAutoDetectBegin callback is called, the
server implementation may initialize any related handling here.
If the server implementation determines, that no further handling is
required, it can end the autodetection phase by returning
FREERDP_AUTODETECT_STATE_COMPLETE.
If not, and an autodetection request is sent, it returns
FREERDP_AUTODETECT_STATE_REQUEST.
The state machine of the connection sequence will then switch into the
IN_PROGRESS state.
In the IN_PROGRESS state, any incoming PDU is handled first, then the
OnConnectTimeAutoDetectProgress callback is called.
Like in the BEGIN state, the return value will determine, whether the
state machine of the connection sequence goes into the END state or goes
into (or rather stays) in the IN_PROGRESS state.
The client tries to connect using RDSTLS only when it has received a
server redirection PDU with LB_PASSWORD_IS_ENCRYPTED flag.
The server exposes RDSTLS on negotiation if it has been configured on settings.
Then authenticates a client using configured credentials from settings:
RedirectionGuid, Username, Domain, Password.
most protocol internal caches do not need to be exposed. this reduces
the public API and allows us to more easily improve/change this during a
release cycle
* Remove duplications in rdpRsaKey, reuse rdpCertificate for public
components
* Move all private key and certificate code to certificate.c,
remove the tssk_* variables from gcc
* Handle update of client and server random keys in wrapping functions
* Simplify gcc_write_server_security_data, use certificate.c functions
to write the certificate data
* Refactor security_establish_keys, use the random values stored in
settings directly
