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 updates to those products.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
Windows Client
Windows NT operating system
Windows 2000 Professional operating system
Windows XP operating system
Windows Vista operating system
Windows 7 operating system
Windows 8 operating system
Windows 8.1 operating system
Windows 10 operating system
Windows 11 operating system
Windows Server
Windows NT Server operating system
Windows 2000 Server operating system
Windows Server 2003 operating system
Windows Server 2003 R2 operating system
Windows Server 2008 operating system
Windows Server 2008 R2 operating system
Windows Server 2012 operating system
Windows Server 2012 R2 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows Server 2025 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates 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 2.1: Protocol towers based on Banyan Vines, DECnet, and Microsoft Message Queuing (MSMQ) are deprecated and are only supported on Windows NT and Windows 2000 operating system.
<2> Section 2.1.1.1: In Windows NT and Windows 2000, IPv6 addresses are not supported.
<3> Section 2.1.1.2: In Windows NT and Windows 2000 IPv6 addresses are not supported.
<4> Section 2.1.1.2: The protocol identifier 0x10 was implemented by legacy versions of Windows for historical reasons and is preserved by current versions for backward compatibility.
<5> Section 2.1.1.2: Windows always asks the Server Message Block implementation to execute a transaction over the named pipe for all PDUs except bind and bind_ack on the client for synchronous RPC calls that do not have a communication timeout associated with the RPC call.
<6> Section 2.1.1.3: Only Windows Server 2012 R2 and earlier support this protocol sequence.
<7> Section 2.1.1.4: Only Windows Server 2012 R2 and earlier support this protocol sequence.
<8> Section 2.1.1.4: Windows implementations of NetBIOS require processes to listen on a specific network interface device, and they have no provisions for routing messages between network interfaces that are not directly attached to the same link. For a Windows RPC client and RPC server to communicate, the server has to be listening on a network interface that the client can reach.
<9> Section 2.1.1.4: This protocol identifier was implemented by legacy versions of Windows for historical reasons and is preserved by current versions for backward compatibility.
<10> Section 2.1.1.5: This protocol identifier was implemented by legacy versions of Windows for historical reasons and is preserved by current versions for backward compatibility.
<11> Section 2.1.1.5: Windows implementations of NetBIOS require processes to listen on a specific network interface device, and they have no provisions for routing messages between network interfaces that are not directly attached to the same link. For a Windows RPC client and RPC server to communicate, the server has to be listening on a network interface that the client can reach.
<12> Section 2.1.1.5: Only Windows NT and Windows 2000 support this protocol sequence.
<13> Section 2.1.1.6: Windows implementations of NetBIOS require processes to listen on a specific network interface device, and they have no provisions for routing messages between network interfaces that are not directly attached to the same link. For a Windows RPC client and RPC server to communicate, the server has to be listening on a network interface that the client can reach.
<14> Section 2.1.1.6: Only Windows NT and Windows 2000 support this protocol sequence.
<15> Section 2.1.1.7: Only Windows NT and Windows 2000 support this protocol sequence.
<16> Section 2.1.2: Windows based clients and servers support connectionless RPC exchanges and connectionless RPC transports.
<17> Section 2.1.2.1: When a connectionless RPC server or RPC client runs over UDP on Windows NT 4.0 operating system, the maximum size of a PDU is 1,024 bytes. Details on PDU length and fragmentation of request and response buffers are as specified in [C706] section 12.5.1. When a connectionless RPC server or RPC client runs over UDP on all other versions of Windows, the maximum size of a PDU is 4,096 bytes. Details on PDU length and fragmentation of request and response buffers are as specified in [C706] section 12.5.3.
<18> Section 2.1.2.2: When connectionless RPC exchange occurs over IPX on Windows NT 4.0, the maximum size of a PDU is 1,024 bytes. For details about PDU length and fragmentation of request and response buffers, see [C706] section 12.5.1. When connectionless RPC exchange occurs over IPX on all other versions of Windows, the maximum size of a PDU is 1,464 bytes. For details about PDU length and fragmentation of request and response buffers, see [C706] section 12.5.3.
<19> Section 2.1.2.2: Only Windows NT and Windows 2000 support this protocol sequence.
<20> Section 2.2.1.1.3: Windows uses the algorithm specified in [RFC4122] to generate the UUID.
<21> Section 2.2.1.1.4: Windows–based servers set the context_handle_attributes field to zero.
<22> Section 2.2.1.1.7: Without the installation of additional software, Windows supports the following authentication types:
Security Provider
Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
NT LAN Manager (NTLM)
Kerberos
Netlogon
<23> Section 2.2.1.1.10: The Windows implementation of SMB server operations do not implement SECURITY_DELEGATION functionality.
<24> Section 2.2.1.2.2: Windows NT, Windows 2000 and Windows XP use the same definition of the structure that is specified in [C706] Appendix L.
<25> Section 2.2.1.2.4: Windows treats any value other than the listed possible values as 0x00000000.
<26> Section 2.2.1.2.4: Windows redefines the same method as follows:
Adds the ptr attribute to the object and Ifid parameters.
Removes the [idempotent] method attribute.
The redefined method is as follows.
-
void ept_lookup ( [in] handle_t hEpMapper, [in] unsigned long inquiry_type, [in, ptr] UUID * object, [in, ptr] RPC_IF_ID * Ifid, [in] unsigned long vers_option, [in, out] ept_lookup_handle_t *entry_handle, [in, range(0, 500)] unsigned long max_ents, [out] unsigned long *num_ents, [out, length_is(*num_ents), size_is(max_ents)] ept_entry_t entries[], [out] error_status *status );
Everything else about this method remains as specified in [C706] Appendix O.
<27> Section 2.2.1.2.5: Windows NT, Windows 2000 and Windows XP redefine the method as follows:
Adds the ptr attribute to the obj and map_tower parameters.
Removes the [idempotent] method attribute.
The redefined method is as follows.
-
void __RPC_FAR ept_map ( [in] handle_t hEpMapper, [in, ptr] UUID * obj, [in, ptr] twr_p_t map_tower, [in, out] ept_lookup_handle_t *entry_handle, [in] unsigned long max_towers, [out] unsigned long *num_towers, [out, ptr, size_is(max_towers),length_is(*num_towers)] twr_p_t *ITowers, [out] error_status *status );
Everything else about this method remains as specified in [C706] Appendix O. Note that this redefinition has no wire impact, and therefore, it is interoperable with the [C706] implementation.
<28> Section 2.2.1.2.6: Windows NT 4.0 supports this method. The definition of the method for Windows NT 4.0 operating system Option Pack for Windows NT Server is as specified in [C706] Appendix O. Windows 2000, Windows XP, and Windows Server 2003 preserve the Windows NT 4.0 definition of the method. However, the method performs no operation, returning EPT_S_CANT_PERFORM_OP in the status field.
All other versions of Windows remove all parameters to the method to redefine the method as follows.
-
void ept_insert(void);
This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.
<29> Section 2.2.1.2.7: Windows NT 4.0 supports this method. The definition of the method for Windows NT 4.0 is specified in [C706] Appendix O. Windows 2000, Windows XP, and Windows Server 2003 preserve the Windows NT 4.0 definition of the method. However, the method performs no operation, and returns EPT_S_CANT_PERFORM_OP in the status field.
All other versions of Windows remove all parameters to the method to redefine the method as follows.
-
void ept_delete(void);
This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.
<30> Section 2.2.1.2.9: On Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, this method performs no operation and returns EPT_S_CANT_PERFORM_OP in the status field. On these versions of the operating system, this method is defined as follows.
-
void ept_inq_object ( [in] handle_t hEpMapper, [in] UUID * object, [out] error_status *status );
All other versions of Windows remove all parameters to the method to redefine the method as follows.
-
void ept_inq_object(void);
This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.
<31> Section 2.2.1.2.10: Windows NT 4.0 supports this method. The definition and behavior of the method are as specified in [C706] Appendix O. Windows 2000, Windows XP, and Windows Server 2003 preserve the Windows NT 4.0 definition of the method. However, the method performs no operation, returning EPT_S_CANT_PERFORM_OP in the status field.
All other versions of the Windows remove all parameters to the method to redefine the method as follows.
-
void ept_mgmt_delete(void);
This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.
<32> Section 2.2.1.3.2: This type is not defined in Windows 2000 Server and earlier.
<33> Section 2.2.1.3.3: Windows NT, Windows 2000 and Windows XP use the definition of the method specified in [C706] Appendix Q.
<34> Section 2.2.1.3.4: Windows NT, Windows 2000 and Windows XP use the definition of the method specified in [C706] Appendix Q.
<35> Section 2.2.2.2: Windows ignores the PFC_MAYBE flag when it is present in a PDU.
<36> Section 2.2.2.9: Windows NT and Windows 2000 ignore the RPC extended error information BLOB.
<37> Section 2.2.2.11: Clients on Windows XP operating system Service Pack 2 (SP2) and earlier send undefined octets at the end of the authentication token, if the security provider indicates a shorter length of the authentication token than the sender of the data estimated initially.
<38> Section 2.2.2.13: Clients and servers in Windows Server 2003 operating system with Service Pack 3 (SP3) and earlier do not send the verification trailer for an RPC with the pipe IDL attribute, as specified in [C706] section 4.2. All other versions of Windows will send the verification trailer for an RPC with a pipe IDL attribute only if all the parameters with a pipe attribute are [out] only.
<39> Section 2.2.2.13: Stub padding octets are sent by Windows 2000 Server operating system Service Pack 4 (SP4) through Windows Server 2003 with SP3.
<40> Section 2.2.2.13: Support for verification trailers is present on Windows 2000 Server SP4 through Windows Server 2003 with SP3. The parts of the verification trailer that are used by Windows and when is specified in sections 2.2.2.13.3 and 2.2.2.13.4.
<41> Section 2.2.2.13.2: In Windows, this verification trailer command is sent only for the first request on a connection.
<42> Section 2.2.2.13.3: In Windows, this verification trailer command is sent for every request when the security provider does not support header signing. Windows does not send this verification trailer if the security provider being used is RPC_C_AUTHN_GSS_NEGOTIATE, RPC_C_AUTHN_WINNT, RPC_C_AUTHN_GSS_KERBEROS or RPC_C_AUTHN_NETLOGON.
<43> Section 2.2.2.13.4: In Windows, this verification trailer command is sent on the first request PDU that uses an abstract_syntax and transfer_syntax that were previously sent on a bind or alter_context PDU.
<44> Section 2.2.3: Only Windows Server 2003 and earlier support connectionless RPC messages.
<45> Section 2.2.3.3: PF2_UNRELATED is not set in Windows NT Server 4.0 operating system.
<46> Section 2.2.3.5: Only clients in Windows XP operating system Service Pack 1 (SP1) and earlier send undefined octets at the end of the authentication token if the security provider indicates a shorter length of the authentication token than the sender of the data estimated initially.
<47> Section 2.2.3.5: These extensions require the model specified in [RFC2743] for all interactions with all security providers. An implementation instructs the GSS-compatible security provider to operate in a DCE-compatible manner by setting the DCE Style protocol variable. The following table details what PDU type carries (in its token section) the output of the GSS [GSS] call. Note that the first call to GSS_Init_sec_context generates no token transmitted to the server and that there is no support for a provider requiring more than two calls to GSS_Init_sec_context or GSS_Accept_sec_context.
<48> Section 2.2.3.6: The Windows implementation always sends the fack PDU with the vers field set to 1.
<49> Section 2.2.4.3: Arrays of context handles are not supported Windows NT, Windows 2000, Windows XP, and Windows Server 2003.
<50> Section 2.2.4.5: In the Windows version of the Microsoft Interface Definition Language (MIDL), this is accomplished by compiling with the ms_union MIDL compiler option on MIDL compilers, starting with version 3.01.75.
<51> Section 2.2.4.7: Windows supports a subset of the expressions allowed in C language in both NDR64 transfer syntax and when target level 6.0 strict NDR/NDR64 data consistency check is requested. The subset is the same in both cases.
<52> Section 2.2.4.13: Windows implementation indicates the octet stream as invalid if the provided byte count is not big enough to contain all the memory needed to unmarshal the pointer indicated by the other pointer parameter. byte_count is not supported in NDR64 transfer syntax.
<53> Section 2.2.5: NDR64 is available on 64-bit versions of Windows. NDR64 is not available for connectionless RPC. NDR64 is not available on Windows NT and Windows 2000.
<54> Section 2.2.5.3.2.1: A conformant array can contain, at most, 231-1 elements in Windows.
<55> Section 2.2.5.3.2.2: A varying array can contain, at most, 231-1 elements in Windows.
<56> Section 2.2.5.3.2.3: In Windows, a conformant varying array can contain, at most, 231-1-o elements where o is the offset.
<57> Section 2.2.6.1: If the endianness is not 0x10 indicating little-endian, Windows assumes big-endian, as specified in section 2.2.6.1.
<58> Section 2.2.7.1: During unmarshaling, Windows ignores the value of the InterfaceID field.
<59> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server.
<60> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server.
<61> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server.
<62> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server. The default value for Windows based servers is 0. The default value for Windows based clients is 1.
<63> Section 3.1.1.5.1.1.2: The Windows system always selects the leftmost [in] handle as the binding handle.
<64> Section 3.1.1.5.3.2: This level of strict NDR/NDR64 data consistency check is enabled by using target robust compiler option, using a MIDL compiler. Target level 5.0 strict NDR/NDR64 data consistency check is not available in Windows NT.
<65> Section 3.1.1.5.3.2.2.1: If the maximum memory size exceeds 231-1 bytes for a conformant structure, conformant varying structure, conformant array, conformant varying array, or conformant and varying string, the octet stream is indicated as invalid.
<66> Section 3.1.1.5.3.2.2.5: Interfaces using auto_handle are rejected in this level of consistency check.
<67> Section 3.1.1.5.3.3: This level of strict NDR/NDR64 data consistency check is enabled by using the target NT60 compiler option, using a MIDL compiler. Target level 6.0 strict NDR/NDR64 data consistency check is not available on clients and servers Windows Server 2003 and earlier.
<68> Section 3.1.1.5.3.3.1.2: This behavior is not available in clients and servers Windows Server 2003 and earlier when the IDL file is compiled for target level 6.0 strict NDR/NDR64 data consistency check. This behavior is turned off if the IDL file is compiled with MIDL command backward_compat switch option maybenull_sizeis.
<69> Section 3.1.1.5.4: By default, Windows based clients and servers Windows Server 2008 R2 and earlier allow remote anonymous calls; otherwise, remote anonymous calls are not allowed. For details and how to change this behavior, see [MSFT-RPCIFRESTRICTION].
<70> Section 3.1.2.7.1.6: These additional client conformant validation checks are not available in clients and servers Windows Server 2003 and earlier. Users can disable these validations through registry and/or application compatibility settings. There is no validation support for multiple dimension conformant/varying arrays. A subset of the rules specified in this section are available in Windows Server 2003 operating system with Service Pack 1 (SP1), as listed. These validations can be disabled by Windows registry settings.
Validations are available for parameter-level correlation only. There is no support for embedded pointers, arrays, or structures.
Validations are available for NDR transfer syntax only. There is no support for NDR64 transfer syntax.
Conformant array, conformant varying array, or conformant varying string parameter are declared earlier in the parameter list before the parameter describing the conformance.
Conformance can only be specified by dereference of another parameter, the value of another parameter plus one, the value of another parameter minus one, the value of another parameter multiplied by two, or the value of another parameter divided by two.
There is no validation support for a conformant varying string whose maximum count is not specified by another parameter.
<71> Section 3.1.3.3.1: On Windows, the endpoint mapper does not listen on a protocol sequence until at least one server using dynamic endpoints on the system starts to listen on that protocol sequence.
<72> Section 3.1.3.5.1: Windows provides a configuration setting to limit the size of server stub memory allocation.
<73> Section 3.2: Windows based clients and servers support connectionless RPC protocol variants.
<74> Section 3.2.1.5.1: Windows NT 4.0 will only interoperate if the response fits into a single unfragmented response. A client can interoperate using multiple fragmented response packets with a server running on Windows 2000, Windows XP or Windows Server 2003.
<75> Section 3.2.1.5.1: Windows NT 4.0 does not have support for Kerberos.
<76> Section 3.2.1.5.2: In Windows, RPC provides a set of asynchronous call invocation APIs. See section 8.1 for APIs listing.
<77> Section 3.2.1.5.2: Only Windows NT 4.0 does not support multiple simultaneous active calls in a single activity.
<78> Section 3.2.1.5.3: The version-specific constant is 0x10000 for RPC servers that run on Windows based clients and is 0x40000 for RPC servers that run on Windows based servers. RPC clients use 0x2000.
<79> Section 3.2.2.1.4: In all versions of Windows, sequence numbers (and representations including Lowest-Allowed-Sequence Counter and Lowest-Unused-Sequence Counter) will "wrap around" to zero (0) if the next sequence number exceeds the maximum value for an unsigned 32-bit data type.
<80> Section 3.2.2.2.2: Windows RPC provides the API RpcAsyncCancelCall to set the F_CANCELED flag.
<81> Section 3.2.2.2.4: Windows NT 4.0 does not implement this timer.
<82> Section 3.2.2.4.1.3: Windows does not check the expiration of the security context.
<83> Section 3.2.2.5.2: Windows silently discards PING packets.
<84> Section 3.2.2.5.6: Windows follows the guidance specified in section 3.2.2.5.6. If the client has accepted five consecutive NOCALL packets containing a packet body with a window_size greater than 0, the call state is changed to STATE_FAULT.
<85> Section 3.2.2.6.1: In Windows RPC clients, set this interval to a constant value of 120 seconds.
<86> Section 3.2.2.6.1: In Windows RPC clients, set this interval to a constant value of 30 seconds.
<87> Section 3.2.3.1.6: In Windows NT 4.0, at most, one call can be in progress per activity. When a packet of a higher sequence number is accepted, the call with the lower sequence is canceled, and the higher number becomes the new lowest-allowed-sequence.
<88> Section 3.2.3.2.1: In Windows NT 4.0, the timer interval is always three seconds. In all other versions of Windows, the interval is effectively infinite: The server sends a burst of packets only in response to a client packet.
<89> Section 3.2.3.2.2: In Windows RPC servers, set this interval to a constant value of 30 seconds.
<90> Section 3.2.3.4.1: In Windows, the server implementation of the application protocol layer indicates to the RPC runtime that the error is handled at the RPC protocol layer by raising an exception.
<91> Section 3.2.3.5.3: Windows-based servers follow this clause, except that the dc_rpc_cl_pkt_hdr_t.auth_proto check is skipped when the PDU type is PING or the maybe flag ([C706]) is set in the dc_rpc_cl_pkt_hdr_t.flags1 field.
<92> Section 3.2.3.5.4: Windows NT 4.0 has the following behavior when receiving this packet: Find or create an activity object for the activity ID in the header. If the activity's lowest-allowed-sequence number is higher than the packet sequence number, discard the packet. If no active call exists with the packet sequence, create a call with that sequence in STATE_INIT and add it to the activity. Set the activity's lowest-allowed-sequence to the packet sequence. Process the packet according to the call state.
<93> Section 3.2.3.5.5: Windows-based servers answer the PING only if its serial number is higher than the serial number of any client packet previously seen in this call.
<94> Section 3.2.3.6.1: In Windows RPC servers, set this interval to a constant value of 30 seconds.
<95> Section 3.2.3.6.1: In Windows RPC servers, implement the idle scavenger timer event as a delayed procedure that is asynchronously called from a thread whose dynamic priority boosting is disabled. As a result, the scan for scavenging idle calls and activities could be delayed. To alleviate this, after receiving a new packet and dispatching to its activity's call, if the idle scavenger timer has already expired, then the server processes idle scavenging.
<96> Section 3.2.3.6.1: In Windows RPC servers set this interval to a constant value of 15 seconds.
<97> Section 3.3.1.5.1: Servers return a PDU indicating an error depending on the received PDU with the invalid version number, as specified in section 3.3.3.5.7.
<98> Section 3.3.1.5.2.1: In the following list Windows assumes the security providers use three legs, see section 2.2.1.1.7:
Security Provider
NTLM
NetLogon
<99> Section 3.3.1.5.3: Windows clients and servers in Windows Server 2003 and earlier do not support the bind time feature negotiation, the server uses the behavior specified in [C706], and the client does not indicate support for bind time feature negotiation and security context multiplexing. Otherwise, the server uses the message processing rules in this section, and clients always indicate support for bind time feature negotiation and for security context multiplexing. Windows allows a client to disable proposing use of the bind time feature negotiation through configuration.
<100> Section 3.3.1.5.3: Windows-based clients in Windows Server 2003 and earlier do not use security context multiplexing on this connection.
<101> Section 3.3.1.5.3: Windows-based clients in Windows Server 2003 and earlier do not support keeping the connection open after sending the orphaned PDU. Also, Windows-based servers in Windows Server 2003 and earlier do not support keeping the connection open after receiving the orphaned PDU.
<102> Section 3.3.1.5.4: Windows-based clients and servers do not send authentication information in this case.
<103> Section 3.3.1.5.4: A Windows-based client that is capable of security context multiplexing does not build more than 1,000 security contexts per connection.
<104> Section 3.3.1.5.4: Windows NT 4.0 and Windows 2000 do not enforce a limit of security contexts per connection; otherwise, Windows enforces a limit of 2,048 security contexts per connection.
<105> Section 3.3.1.5.6: Windows-based clients return error RPC_S_UNSUPPORTED_TRANS_SYN.
<106> Section 3.3.1.5.6: Windows-based clients negotiate a transfer syntax in parallel with marshaling data using transfer syntax NDR in cases where an existing connection does not support both the NDR and NDR64 (2.2.5) transfer syntaxes or there are multiple transfer syntax bindings that are available but no preferred transfer syntax. In such cases, the client always proposes NDR as one of the transfer syntaxes, and, if the server accepts a transfer syntax different from NDR, the client attempts to renegotiate transfer syntax NDR, which is used to send the requests already marshaled. But the server-accepted transfer syntax in the first negotiation is used for requests that have not started transfer syntax negotiation by the time the first negotiation completed.
<107> Section 3.3.1.5.8: Windows NT does not support concurrent multiplexing on a connection.
<108> Section 3.3.2.1.3: The Windows API to set this value is the RpcBindingSetOption() function with Option set to RPC_C_OPT_CALL_TIMEOUT.
<109> Section 3.3.2.1.5: Windows NT Server 4.0 does not set the bind time-out value. Windows implementations use the RpcMgmtSetComTimeout API.
<110> Section 3.3.2.2.1: Only NCACN_IP_TCP makes use of this timer. The RPC runtime on the client instructs the TCP/IP stack on the client to use a potentially smaller value than the default for the TCP keep-alives to monitor the state of the connection. The value used for the timer is determined by a higher-level protocol. A higher-level protocol passes a value between 0 and 10, and, in Windows 2000 through Windows Server 2012 R2, the RPC runtime on the client uses these values as an indication of how long to wait for a response from the server before it turns on keep-alives. The value passed in by a higher-level protocol is interpreted according to the following table. The default is time-out parameter 5. Once the keep-alives are turned on, the implementation of these extensions instruct the TCP/IP stack to send one keep-alive packet every second.
|
Time-out parameter |
Actual delay before turning on keep-alives (in seconds) |
|---|---|
|
0 (RPC_C_BINDING_MIN_TIMEOUT) |
120 |
|
1 |
240 |
|
2 |
360 |
|
3 |
480 |
|
4 |
600 |
|
5 (RPC_C_BINDING_DEFAULT_TIMEOUT) |
720 |
|
6 |
840 |
|
7 |
960 |
|
8 |
1,080 |
|
9 (RPC_C_BINDING_MAX_TIMEOUT) |
1,200 |
|
10 (RPC_C_BINDING_INFINITE_TIMEOUT) |
Never |
<111> Section 3.3.2.4.1.3: The RPC runtime on the Windows client can obtain the credentials from a higher-level protocol that can supply a user name/domain/password, or it can use the implicit credentials of the logon session that is attached to the thread on which the call is made.
<112> Section 3.3.2.4.1.4: In Windows, the higher layer protocol can use the RpcMgmtEnableIdleCleanup function.
<113> Section 3.3.2.5.1: Windows-based clients return error code 0x6C0 (RPC_S_PROTOCOL_ERROR) to the client application in this case.
<114> Section 3.3.2.6.2: Windows defines a threshold of existing connections above which the system will apply a more aggressive timeout. This value is fixed to 500.
<115> Section 3.3.2.6.2: Windows defines a threshold of existing security contexts above which the system will apply a more aggressive timeout. This value is fixed to 500.
<116> Section 3.3.2.6.3: In Windows, the application of this protection is triggered through configuration or APIs available to higher layers. The following table lists the Windows behavior for the various security providers:
|
Security provider |
Security information applied for endpoint mapper requests |
|---|---|
|
Kerberos |
NTLM |
|
NTLM |
NTLM |
|
Simple and Protected GSS-API Negotiation Mechanism |
NTLM |
|
Netlogon |
None |
<117> Section 3.3.3.2.1: Only NCACN_IP_TCP makes use of this timer. The RPC runtime on the server instructs the TCP/IP stack on the server to use a potentially smaller value than the default for the TCP keep-alives to monitor the state of the connection. The value used for the timer is determined by a higher-level protocol. A higher-level protocol passes a value between 0 and 10, and the RPC runtime on the server uses these values as an indication of how long to wait for a packet from the client before it turns on keep-alives. The value passed in by a higher-level protocol is interpreted according to the same table that is specified in section 3.3.2.2.1 product note. The default is parameter value 5. Once the keep-alives are turned on, the implementation of these extensions instruct the TCP/IP stack to send one keep-alive packet every second. This behavior is not supported on Windows NT, Windows 2000, and Windows XP.
<118> Section 3.3.3.3.1.3: In Windows, the name of the security provider module is retrieved from the registry by using the authentication_type constant supplied by the higher-level protocol.
<119> Section 3.3.3.4.1: In Windows, the server implementation of the application protocol layer indicates to the RPC runtime that the error is handled at the RPC protocol layer by raising an exception.
<120> Section 3.3.3.4.2: Windows-based servers never send shutdown packets.
<121> Section 3.3.3.4.3.1: The Windows equivalent of GSS_Inquire_context is known as QueryContextAttributes (Negotiate), the access token is retrieved by specifying SECPKG_ATTR_ACCESS_TOKEN as the attribute of the context to be returned. (See [MSDN-QueryContextAttributes]).
<122> Section 3.3.3.4.3.2: The Windows equivalent of GSS_Inquire_context is known as QueryContextAttributes (Negotiate), the token is retrieved by specifying SECPKG_ATTR_ACCESS_TOKEN as the attribute of the context to be returned. (See [MSDN-QueryContextAttributes].)
<123> Section 3.3.3.5.2: Windows systems reject call_id values greater than 0x7FFFFFFF and do not allow call_id rollover.
<124> Section 3.3.3.5.4: This behavior can be turned off by higher-level protocols or machine configuration. Note that the limit on Windows 2000 is 1 megabyte; Windows NT 4.0 does not implement such a limit.
<125> Section 3.3.3.5.6: This message handling is not present in Windows XP SP1 and earlier.