FreeRDP
rpc_bind.c File Reference
#include <winpr/crt.h>
#include <freerdp/log.h>
#include "rpc_client.h"
#include "rpc_bind.h"

Macros

#define TAG   FREERDP_TAG("core.gateway.rpc")
 

Functions

int rpc_send_bind_pdu (rdpRpc *rpc)
 
int rpc_recv_bind_ack_pdu (rdpRpc *rpc, BYTE *buffer, UINT32 length)
 
int rpc_send_rpc_auth_3_pdu (rdpRpc *rpc)
 

Variables

const p_uuid_t TSGU_UUID
 
const p_uuid_t NDR_UUID
 
const p_uuid_t BTFN_UUID
 

Macro Definition Documentation

#define TAG   FREERDP_TAG("core.gateway.rpc")

FreeRDP: A Remote Desktop Protocol Implementation RPC Secure Context Binding

Copyright 2012 Marc-Andre Moreau marca.nosp@m.ndre.nosp@m..more.nosp@m.au@g.nosp@m.mail..nosp@m.com

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Function Documentation

int rpc_recv_bind_ack_pdu ( rdpRpc *  rpc,
BYTE buffer,
UINT32  length 
)

Maximum Transmit/Receive Fragment Size Negotiation

The client determines, and then sends in the bind PDU, its desired maximum size for transmitting fragments, and its desired maximum receive fragment size. Similarly, the server determines its desired maximum sizes for transmitting and receiving fragments. Transmit and receive sizes may be different to help preserve buffering. When the server receives the client’s values, it sets its operational transmit size to the minimum of the client’s receive size (from the bind PDU) and its own desired transmit size. Then it sets its actual receive size to the minimum of the client’s transmit size (from the bind) and its own desired receive size. The server then returns its operational values in the bind_ack PDU. The client then sets its operational values from the received bind_ack PDU. The received transmit size becomes the client’s receive size, and the received receive size becomes the client’s transmit size. Either party may use receive buffers larger than negotiated — although this will not provide any advantage — but may not transmit larger fragments than negotiated.

SECURE_BIND_ACK: RPC bind_ack PDU with sec_trailer and auth_token. The PFC_SUPPORT_HEADER_SIGN flag in the PDU header is also set in this example. Auth_token is generated by the server in the previous step. Upon receiving that PDU, the client calls the implementation equivalent of the abstract GSS_Init_sec_context call, which returns an auth_token and continue status in this example.

Here is the call graph for this function:

Here is the caller graph for this function:

int rpc_send_bind_pdu ( rdpRpc *  rpc)

Secure Connection-Oriented RPC Packet Sequence

Client Server | |

-------------——SECURE_BIND--------------——>
<----------——SECURE_BIND_ACK-------------——
--------------——RPC_AUTH_3--------------——>
------------——REQUEST_PDU_#1------------——>
------------——REQUEST_PDU_#2------------——>
...
<-----------——RESPONSE_PDU_#1------------——
<-----------——RESPONSE_PDU_#2------------——
...

SECURE_BIND: RPC bind PDU with sec_trailer and auth_token. Auth_token is generated by calling the implementation equivalent of the abstract GSS_Init_sec_context call. Upon receiving that, the server calls the implementation equivalent of the abstract GSS_Accept_sec_context call, which returns an auth_token and continue status in this example. Assume the following:

1) The client chooses the auth_context_id field in the sec_trailer sent with this PDU to be 1.

2) The client uses the RPC_C_AUTHN_LEVEL_PKT_PRIVACY authentication level and the Authentication Service (AS) NTLM.

3) The client sets the PFC_SUPPORT_HEADER_SIGN flag in the PDU header.

Here is the call graph for this function:

Here is the caller graph for this function:

int rpc_send_rpc_auth_3_pdu ( rdpRpc *  rpc)

RPC_AUTH_3: The client knows that this is an NTLM that uses three legs. It sends an rpc_auth_3 PDU with the auth_token obtained in the previous step. Upon receiving this PDU, the server calls the implementation equivalent of the abstract GSS_Accept_sec_context call, which returns success status in this example.

Here is the call graph for this function:

Here is the caller graph for this function:

Variable Documentation

const p_uuid_t BTFN_UUID
Initial value:
=
{
0x6CB71C2C,
0x9812,
0x4540,
0x03,
0x00,
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
}
const p_uuid_t NDR_UUID
Initial value:
=
{
0x8A885D04,
0x1CEB,
0x11C9,
0x9F,
0xE8,
{ 0x08, 0x00, 0x2B, 0x10, 0x48, 0x60 }
}
const p_uuid_t TSGU_UUID
Initial value:
=
{
0x44E265DD,
0x7DAF,
0x42CD,
0x85,
0x60,
{ 0x3C, 0xDB, 0x6E, 0x7A, 0x27, 0x29 }
}

Connection-Oriented RPC Protocol Client Details: http://msdn.microsoft.com/en-us/library/cc243724/