List of Remote Procedure Call (RPC) fixes in Windows XP Service Pack 2 and in Windows XP Tablet PC Edition 2005

This article lists the Remote Procedure Call (RPC) issues and update scenarios that are addressed in Microsoft Windows XP Service Pack 2 (SP2) and in Windows XP Tablet PC Edition 2005.

For additional information about the issues that are resolved in Windows XP SP2, click the following article number to view the article in the Microsoft Knowledge Base:

The RPC issues and update scenarios that are addressed are listed as follows:

Update to add three new RPC interface registration flags

This update introduces the following interface registration flags to RPC:

• The RPC_IF_LOCAL_ONLY flag
  
  When this flag is registered, the RPC runtime rejects calls that are made by remote clients. All local calls that use ncadg_* and ncacn_* protocol sequences are also rejected, except for local calls that use the ncacn_np sequence.
• The RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag
  
  When this flag is registered, the RPC runtime invokes the registered security callback for all calls, regardless of the call security settings. Without this flag, RPC rejects all unauthenticated calls before the calls reach the security callback. This flag works only when a security callback is registered.
• The RPC_IF_SEC_NO_CACHE flag
  
  Use this flag to disable security callback caching for a particular interface. You may want to do this in situations where the security check may change or where a client identity that was previously permitted may possibly be rejected.

Update to restrict anonymous remote RPC access

Typically, the RPC protocol permits anonymous remote access for interfaces that do not specifically request restricted access. This update introduces the RestrictRemoteClients DWORD registry entry that you can configure to control this behavior. This entry is located in the following registry subkey:Set the RestrictRemoteClients registry entry to use one of the following values, depending on your situation:

• 0
  This setting permits anonymous remote access to interfaces.
• 1 (default)
  This default setting permits access to interfaces only by using authenticated connections, unless those connections specifically request to be exempt from this requirement.
  
  Note This exemption is required for some DCOM scenarios.
• 2
  This setting permits remote access to interfaces only by using authenticated connections. This setting does not permit exceptions to the authentication requirement.

Update to configure an RPC client to use authentication to communicate with the endpoint mapper

Typically, an RPC client does not use authentication when it communicates with the RPC endpoint mapper. Currently, an RPC client that tries to make a call by using a dynamic endpoint will first query the RPC endpoint mapper on the server to determine what endpoint to connect to. This query is performed anonymously, even if the RPC client call is performed by using RPC security.

This update introduces the EnableAuthEpResolution registry DWORD entry that you can configure to control this behavior. This new registry entry is required to enable an RPC client to make a call to an RPC server that has registered a dynamic endpoint on a system that is running Windows XP SP2. The client computer must set this registry key so that it will perform an authenticated query to the RPC endpoint mapper. The EnableAuthEpResolution registry entry is located in the following registry subkey: Set the EnableAuthEpResolution registry entry to use one of the following values, depending on your situation:

• 0
  This value configures client computers not to use authentication when they communicate with the endpoint mapper on a server.
• 1 (default)
  When you use this value, the client computer uses authentication in the endpoint mapper request to the server if the endpoint mapper query is in the context of an authenticated RPC call.

Certain Interface Definition Language (IDL) constructs are marshaled and unmarshaled incorrectly by RPC

Programs that use RPC to communicate with other Microsoft Windows-based computers over a network may fail. For example, when you use a custom Microsoft Visual Basic program between two remote computers, and the Visual Basic program uses user-defined type marshaling, you may find that certain IDL constructs are incorrectly marshaled and unmarshaled. For example, you may experience one of the following symptoms:

• The remote call fails, and an RPC_X_BAD_STUB_DATA error code is returned by the Visual Basic program.
• Incorrect data is unmarshaled.

An incorrect error code mapping exists in RPC

If a security callback that occurs from a RPC interface returns error code 1717, the Local RPC (LRPC) code in Windows incorrectly converts this error code to error code 5, "Access Denied."

Update to add settings for the RestrictRemoteClients option and the EnableAuthEpResolution option to the System.adm file

This update adds settings for the RPC RestrictRemoteClients option and the EnableAuthEpResolution option to the System.adm Group Policy administrative template.

The RPC component incorrectly handles the STATUS_UNSUCCESSFUL status code

The RPC component in Windows does not correctly handle an error code that indicates that the operating system has run out of pool memory. Because this error code is handled incorrectly, a session that exists with a server ends. Therefore, a premature exhaustion of context handles occurs.

Update to change the RpcBindingSetAuthInfoEx function to no longer require the SEC_WINNT_AUTH_IDENTITY structure to be valid for the lifetime of the binding handle

The current RpcBindingSetAuthInfoEx function requires that the SEC_WINNT_AUTH_IDENTITY structure that is passed to the function is valid for the lifetime of the binding handle. This structure contains user-sensitive information, such as password information.

This update modifies the code so that the MSDN requirement to keep clear text credentials in memory applies only to the scenario where the RpcBindingInqAuthInfo(Ex) function is called. For other cases, the credentials do not have to be kept available. In these other scenarios, the clear text credentials are copied and encrypted. Therefore, the user-passed credential parameter may be freed.

Update to automatically open port 135 in Windows Firewall when a TCP or a UDP RPC server registers with the endpoint mapper

RPC programs that are permitted from the perspective of Windows Firewall and that use dynamic endpoints cannot communicate unless you manually open port 135 or port 593. This update modifies the RPC protocol to call an additional Windows Firewall API. This API does the following for programs that are permitted by Windows Firewall and that use dynamic endpoints:

• Automatically opens TCP port 135 for TCP protocol sequences
• Automatically opens TCP port 593 for HTTP protocol sequences

Update to import the features and functionality of the RPC over HTTP component from Microsoft Windows Server 2003

The RPC over HTTP component in Windows Server 2003 includes many security updates and functionality updates over that of Windows XP. This update incorporates the updated features and functionality from the RPC over HTTP component in Windows Server 2003 to Windows XP with SP2.

You receive an "0x800706f7" error message if an embedded user-defined type has a buffer size that is more than 16 megabytes (MB)

You may find that you cannot pass a user-defined type across processes if the user-defined type has a buffer size that is more than 16 MB. When you try to pass a UDT that is larger than 16 MB across processes, you may receive an error message that is similar to the following:



For more information about the changes to functionality in Windows XP SP2 network protection technologies, visit the following Microsoft Web site: