Export (0) Print
Expand All

7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows XP operating system Service Pack 2 (SP2)

  • Windows Server 2003 operating system with Service Pack 1 (SP1)

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 1: This protocol was called the Terminal Services Gateway Server Protocol in the following operating systems: Windows XP, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008 and Windows 7.

<2> Section 1: This gateway was called the Terminal Services Gateway Server Protocol in the following operating systems: Windows XP, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008 and Windows 7.

<3> Section 1.1: This client was called the RDG client in the following operating systems: Windows XP, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, and Windows 7.

<4> Section 1.1: This server was called the RDG server in the following operating systems: Windows XP, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, and Windows 7.

<5> Section 1.3: The Windows RDPclient uses the RDGSP Protocol as a transport mechanism to establish a connection to a target server behind a firewall. The connection frequently originates from a client located on the Internet. The RDGSP Protocol may also be used to connect to an isolated target server from clients located on a different private network. An RDGSP Protocol server serves as the termination point for the tunnel and relays RDPclient data to and from the target server by using the channel.

<6> Section 1.3.2: Support for the HTTP transport is available as follows:

TSGU client

  • Windows 7 with RDP 8.0/8.1 Client Update

  • Windows Server 2008 R2 with RDP 8.0/8.1 Client Update

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

TSGU server

  • Windows Server 2012

  • Windows Server 2012 R2

<7> Section 1.3.3: Support for UDP transport is available in Windows 8 and Windows Server 2012.

<8> Section 2.2.5.2.19: Only Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 support Consent Message, Service Message, Idle Timeout, and Reauthentication.

<9> Section 2.2.6.1: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 are capable of exchanging policies with the RDG server. Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, and Windows Server 2008 are not capable of exchanging policies with the RDG server.

<10> Section 2.2.9.1: Windows Server 2003 with SP1, Windows XP SP2, and Windows Vista send a list of IP addresses in the resourceName field and NetBIOS or FQDN names in alternateResourceNames when it is redirected by the TS session directory.

<11> Section 2.2.9.2.1.2: Windows XP SP2, Windows Vista, Windows Server 2003 with SP1, Windows Server 2008, and Windows Server 2008 R2 send quarantineCapabilities type 1—indicating that each understands network access protection capability. Based on quarantine policies set on Windows Server 2008, it will require quarantine information be sent from client to server.

<12> Section 2.2.9.2.1.2.1: Windows XP SP2, Windows Vista, Windows Server 2003 with SP1, and Windows Server 2008 send the capability type 0x00000001 indicating that each understands NAP capability. Based on quarantine policies set on Windows Server 2008, it will require quarantine information to be sent from client to server.

<13> Section 2.2.9.2.1.3: The TSG_PACKET_QUARCONFIGREQUEST structure is not used by any version of Windows. If this structure is used, an error code of HRESULT_CODE(E_PROXY_NOTSUPPORTED) is returned.

<14> Section 2.2.9.2.1.4: If Windows Server 2008 requires that quarantine information be sent, the client's health is queried using quarantine agent and is sent to the Windows Server 2008 in an encrypted manner. If this data is not present and quarantine is required by Windows Server 2008, the server rejects the TsProxyAuthorizeTunnel call with an E_PROXY_QUARANTINE_ACCESSDENIED (0x800759ED) response.

<15> Section 2.2.9.2.1.4: Windows Server 2008 uses machineName value to determine the machine domain membership based on the network access policies set by the administrator on the server.

<16> Section 2.2.9.2.1.4: Windows XP SP2, Windows Server 2003 with SP1, and Windows Vista obtain the statement of health from the NAP agent and encrypt it using the certificate sent by the server during the TsProxyCreateTunnel method. Windows Server 2008 decrypts the statement of health from the client using the private key corresponding to the same certificate it sent to the client during the tunnel creation. If the packet contains health data, Windows Server 2008 performs all access checks, including quarantine, and network policies in this call to allow operations on the tunnel.

<17> Section 2.2.9.2.1.5: In Windows Server 2008, responseData is ignored and responseDataLen is set to zero.

Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 may send the statement of health response (SoHR) and idle timeout values, depending on its policies. The statement of health response is signed and encoded using the RDG server's private key. The RDG client sends the statement of health response to the NAP agent, which verifies and decodes the data using the server public key that was passed during a call to TsProxyCreateTunnel. If the RDG server can support idle timeout as specified in section 2.2.9.2.1.2.1.2, then the idle timeout is prepended to the statement of health response.

Idle timeout is configured on the RDG server and is enforced on the RDG client. Only Windows Server 2008 R2 RDG server supports idle timeout.

<18> Section 2.2.9.2.1.5: Windows Server 2008 sends the redirectionFlags value based on network policies configured for Windows terminal server. Regarding the details of redirectionFlag values please refer to section 2.2.1.27 of [MS-RNAP].

<19> Section 2.2.9.2.1.6: Windows Server 2008 sends the base64-encoded version of the certificate chain if quarantine is required. This certificate is the same as that registered for the RPC_C_AUTHN_GSS_SCHANNEL authentication service.

<20> Section 2.2.9.2.1.9: Windows implementation of RDG server always sets this field to 1 and Windows implementation of RDG client never uses this field.

<21> Section 3.1.1: On machines running Windows, this is the machine name that is returned by the gethostname function.

<22> Section 3.1.1: Windows Server 2003 with SP1, Windows Server 2008, Windows Server 2008 R2, Windows 8, and Windows 8.1 use Tunnel id to map to a Tunnel Context handle, Channel id capabilities information, and user information.

<23> Section 3.1.1: Windows Server 2003 with SP1, Windows Server 2008, Windows Server 2008 R2, Windows 8, and Windows 8.1 use the Channel id for an auditing purpose at server side and to show the connection details to the administrator.

<24> Section 3.1.2.1: The session timeout timer is not implemented in Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows 8, and Windows Server 2012.

<25> Section 3.1.2.2: The re-authentication timer is not implemented in Windows XP SP2, Windows Server 2003 with SP1, Windows Vista, Windows Server 2008, Windows 7, Windows 8, and Windows Server 2012.

<26> Section 3.2.4.1: Windows Server 2008 implements this timer, but Windows Server 2008 R2 does not implement this timer. In Windows Server 2008, if a call to TsProxySetupReceivePipe is not made within 30 seconds of a call to TsProxyCreateChannel, the Windows Server 2008 RDG server will disconnect the connection. The disconnection will occur in order to implement TsProxyCreateChannel. Note that the protocol, however, does not mandate the timer.

<27> Section 3.2.4.1: The timer value is not mandated by the protocol. Different implementations may choose to use this timer if required. The timer value may be set to a value appropriate to the implementation.

<28> Section 3.2.5: Windows Server 2008 uses the identity of the caller to perform method-specific access checks. The RDG service allows only authenticated users to call any method. Windows Server 2008 imposes a minimum impersonation level of RPC_C_IMPL_LEVEL_IDENTIFY ([MS-RPCE] section 2.2.1.1.9) on all method calls. If RDG is operating in a load-balanced environment, Windows Server 2008 registers for the hostname, not the IPv4/IPv6 addresses. Windows Server 2008 registers for RPC_C_AUTHN_GSS_SCHANNEL authentication service using the same certificate that is set for HTTPS communications on the machine.

<29> Section 3.2.6: Windows Server 2008 implementation uses RPC protocol to retrieve the identity of the caller as specified in [MS-RPCE] section 3.2.3.4.2. The server uses the underlying Windows security subsystem to determine the permissions for the caller. If the caller does not have the required permissions to execute a specific method, the method call fails with ERROR_ACCESS_DENIED. This error code is returned to the caller in a rpc_fault packet.

<30> Section 3.2.6: This method is available only in Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2.

<31> Section 3.2.6: Opnums that are not used apply to Windows XP SP2, Windows Vista, Windows Server 2003 with SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2.

Opnum 3 is used only by Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. Windows XP SP2 and Windows Server 2008 do not use opnum 3.

Opnum

Description

0

Reserved for local use.

5

Reserved for local use.

<32> Section 3.2.6.1.1: Pluggable authentication is available only in Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. Windows does not implement any authentication plug-ins, but ISVs can create their plug-ins and use them for authentication.

<33> Section 3.2.6.1.1: In Windows Server 2008, the results are undefined when the TSGPacket is set to anything other than the TSG_PACKET_VERSIONCAPS structure. However, in Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, if the TSGPacket is set to anything other than the TSG_PACKET_VERSIONCAPS structure in case of RPC authentication or TSG_PACKET_AUTH structure in case of pluggable authentication, the error <E_PROXY_INTERNALERROR> is returned.

<34> Section 3.2.6.1.2: Windows implementation of the protocol does user authorization based on user group membership, client computer group membership (optional), user authentication method (password or smartcard), and client computer health status (optional). These authorization conditions are specified using connection authorization policies (CAPs). When the CAPs set by the administrator require RDG client computer health status checks, the RDG server will require that RDG clients send health information and remediate themselves if health check is not met.

<35> Section 3.2.6.1.2: The Windows Server 2008 R2 Standard implementation limits the number of connections to 250.

The Windows Server 2008 R2 Foundation implementation limits the number of connections to 50.

All other Windows implementations allow an unlimited number of connections.

<36> Section 3.2.6.1.4: Windows Server 2008 rejects this call and all channel-related calls if the TsProxyAuthorizeTunnel method call does not succeed. Windows Server 2008 performs access checks to determine if a connection to the target server is allowed by policies in this call.

<37> Section 3.2.6.1.4: Windows Server 2008 does not attempt to connect to the target server during the TsProxyCreateChannel call. The actual connection to the target server happens during the call to TsProxySetupReceivePipe.

<38> Section 3.2.6.1.4: Windows Server 2008 returns HRESULT_CODE(E_PROXY_RAP_ACCESSDENIED), such as 0x000059DA, if resource authorization fails.

<39> Section 3.2.6.1.4: In Windows Server 2008, even if the RESOURCENAME strings in the resourceName member are not valid, ERROR_SUCCESS is returned. In Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, if the RESOURCENAME is not valid, HRESULT_CODE(E_PROXY_TS_CONNECTFAILED) (0x000059DD) is returned.

<40> Section 3.2.6.2.1: Windows Server 2008, Windows Server 2003 with SP1, Windows XP SP2, and Windows Vista do not use the NDR for this call. Windows Server 2008 rejects this call if any discrepancies in the data are noted, such as the data lengths not matching those reported by the server stub.

<41> Section 3.2.6.2.2: To bypass NDR, the Windows implementation of Terminal Services Gateway Server Protocol hooks into the RPC layer directly and reads from the Buffer field of the _RPC_MESSAGE struct defined in [MSDN-RPCMESSAGE].

<42> Section 3.2.6.2.2: Windows Server 2008, Windows Server 2003 with SP1, Windows XP SP2, and Windows Vista do not use the NDR for this call. Windows Server 2003 with SP1, Windows XP SP2, Windows Vista, and Windows Server 2008 disable RPC buffering for this call. The Windows Server 2008 rejects this call if any discrepancies in the data are noted, such as the data lengths not matching those reported by the server stub. Windows Server 2008 makes a socket connection to the target server as part of this call.

<43> Section 3.2.6.2.2: Only Windows Server 2008 attempts to connect to the target server during the TsProxySetupReceivePipe call because it doesn't attempt to connect to the target server during TsProxyCreateChannel call.

<44> Section 3.2.6.2.2: This error is returned only by the Windows Server 2008 RDG server, because only this version attempts connecting to the target server in the TsProxySetupReceivePipe call.

<45> Section 3.3.3.1: In the following TSGU clients the default timer value on the client is 8 minutes.

  • Windows 7 with RDP 8.0/8.1 Client Update

  • Windows Server 2008 R2 with RDP 8.0/8.1 Client Update

  • Windows 8

  • Windows Server 2012

  • Windows 8.1

  • Windows Server 2012 R2

In newer versions of TSGU client, beginning with RDP 8.1, with the updates in the following KBs installed, the default time period is 1 minute.

  • Windows 8.1/Windows Server 2012 R2: KB 2921855

  • RDP 8.1 for Windows 7/Windows Server 2008 R2: KB 2923545

This timer is not supported in the following versions of Windows:

  • Windows XP SP2

  • Windows Server 2003 with SP1

  • Windows Vista

  • Windows Server 2008

<46> Section 3.5.1: On machines running Windows, this is the machine name that is returned by the gethostname function.

<47> Section 3.5.1: Note that the size of the buffer is 513 bytes, even though the contents are 16-bit Unicode characters. This reflects the actual Windows implementation.

<48> Section 3.5.1: On machines running Windows, the Client Machine name refers to the computer name only as returned by the gethostname function.

<49> Section 3.5.3: Windows uses the INapEnforcementClientConnection::GetSoHRequest method to obtain the SoH, which is retrieved in the out parameter as specified in [MSDN-NAPAPI].

<50> Section 3.6.4: Windows uses the INapEnforcementClientConnection::GetSoHRequest method to obtain the SoH, which is retrieved in the out parameter as specified in [MSDN-NAPAPI].

 
Show:
© 2014 Microsoft