3.1.5 Message Processing Events and Sequencing Rules
All Windows Remote Registry Protocol operations begin with the client opening one of the well-known predefined keys on the server. After this key is opened, an RPC context handle MUST be associated with this opened key, as specified in [MS-RPCE], and this handle is returned to the client. The client MUST open a key before performing operations such as opening or creating subkeys, reading or setting values that are associated with this key, or even deleting subkeys.
The server MUST perform the following processing rules for each invocation of each of the methods listed below in this section:
The server ADM element Token MUST be initialized by retrieving the identity token for the current execution context by invoking the abstract interface GetRpcImpersonationAccessToken(NULL) as specified in [MS-RPCE] section 3.3.3.4.3.1.
The server MUST impersonate the client (the security principal of the caller) by invoking the abstract interface RpcImpersonateClient as specified in [MS-RPCE] section 3.3.3.4.3.2, passing in NULL as the BindingHandle parameter.
The server performs the method listed in the following table.
The server MUST stop impersonating the client prior to returning a status code by invoking the abstract interface RpcRevertToSelf as specified in [MS-RPCE] section 3.3.3.4.3.3.
When opening a key, the server then opens the key with the user rights that are requested by the client, provided the client has sufficient permissions for the requested user rights.
The server MUST fail to open a key if the client does not have sufficient permissions for the requested user rights. Similarly, the server MUST also fail specific operations if the key was not opened with sufficient user rights, as specified in section 2.2.3. In addition to validating access against the security descriptors associated with the relevant keys, a server SHOULD<12> perform additional implementation-specific access checks.
The remainder of this section describes the server behavior for the RPC methods that are supported by the Windows Remote Registry Protocol. The protocol clients can invoke the RPC methods that are specified in this section in any order after a Windows Remote Registry Protocol session is established with the server. The outcome of the calls depends on the parameters that are passed to each of those calls.
Methods in RPC Opnum Order
Method |
Description |
---|---|
Called by the client. In response, the server opens the HKEY_CLASSES_ROOT predefined key and returns a handle to the HKEY_CLASSES_ROOT key. Opnum: 0 |
|
Called by the client. In response, the server opens the HKEY_CURRENT_USER predefined key and returns a handle to the HKEY_CURRENT_USER key. Opnum: 1 |
|
Called by the client. In response, the server opens the HKEY_LOCAL_MACHINE predefined key and returns a handle to the HKEY_LOCAL_MACHINE key. Opnum: 2 |
|
Called by the client. In response, the server opens the HKEY_PERFORMANCE_DATA predefined key and returns a handle to the HKEY_PERFORMANCE_DATA key. Opnum: 3 |
|
Called by the client. In response, the server opens the HKEY_USERS predefined key and returns a handle to the HKEY_USERS key. Opnum: 4 |
|
Called by the client. In response, the server releases a handle to the specified registry key. Opnum: 5 |
|
Called by the client. In response, the server creates the specified registry key. If the key already exists in the registry, the function opens it. Opnum: 6 |
|
Called by the client. In response, the server deletes the specified subkey. Opnum: 7 |
|
Called by the client. In response, the server removes a named value from the specified registry key. Opnum: 8 |
|
Called by the client. In response, the server returns the requested subkey. Opnum: 9 |
|
Called by the client. In response, the server enumerates the values for the specified open registry key. Opnum: 10 |
|
Called by the client. In response, the server writes all the attributes of the specified open registry key into the registry. Opnum: 11 |
|
Called by the client. In response, the server returns a copy of the security descriptor that protects the specified open registry key. Opnum: 12 |
|
Called by the client. In response, the server creates a subkey under HKEY_USERS or HKEY_LOCAL_MACHINE and stores registration information from a specified file in that subkey. Opnum: 13 |
|
Opnum14NotImplemented |
Not implemented. Opnum: 14 |
Called by the client. In response, the server opens the specified key for access, returning a handle to it. Opnum: 15 |
|
Called by the client. In response, the server returns relevant information about the key that corresponds to the specified key handle. Opnum: 16 |
|
Called by the client. In response, the server returns the data that is associated with the default value of a specified registry open key. Opnum: 17 |
|
Called by the client. In response, the server MUST read the registry information from the specified file and replace the specified key with the content of the file, so that when the system is restarted, the key and subkeys have the same values as those in the specified file. Opnum: 18 |
|
Called by the client. In response, the server reads the registry information in a specified file and copies it over the specified key. The registry information can take the form of a key and multiple levels of subkeys. Opnum: 19 |
|
Called by the client. In response, the server saves the specified key and all its subkeys and values to a new file. Opnum: 20 |
|
Called by the client. In response, the server sets the security descriptor that protects the specified open registry key. Opnum: 21 |
|
Called by the client. In response, the server sets the data for the default value of a specified registry key. The data MUST be a text string. Opnum: 22 |
|
Called by the client. In response, the server removes the specified discrete body of keys, subkeys, and values that are rooted at the top of the registry hierarchy. Opnum: 23 |
|
Opnum24NotImplemented |
Not implemented. Opnum: 24 |
Opnum25NotImplemented |
Not implemented. Opnum: 25 |
Called by the client. In response, the server returns the version to which a registry key is connected. Opnum: 26 |
|
Called by the client. In response, the server attempts to open the HKEY_CURRENT_CONFIG predefined key and returns a handle to the HKEY_CURRENT_CONFIG key. Opnum: 27 |
|
Opnum28NotImplemented |
Not implemented. Opnum: 28 |
Called by the client. In response, the server returns the type and data for a list of value names that are associated with the specified registry key. Opnum: 29 |
|
Opnum30NotImplemented |
Not implemented. Opnum: 30 |
Called by the client. In response, the server saves the specified key and all its subkeys and values to a new file. Opnum: 31 |
|
Called by the client. In response, the server opens the HKEY_PERFORMANCE_TEXT predefined key and returns a handle to the HKEY_PERFORMANCE_TEXT key. Opnum: 32 |
|
Called by the client. In response, the server opens the HKEY_PERFORMANCE_NLSTEXT predefined key and returns a handle to the HKEY_PERFORMANCE_NLSTEXT key. Opnum: 33 |
|
Called by the client. In response, the server returns the type and data for a list of value names that are associated with the specified registry key. Opnum: 34 |
|
Called by the client. In response, the server deletes the specified subkey. This function differs from BaseRegDeleteKey in that either 32-bit or 64-bit keys can be deleted, regardless of what kind of application is running. Opnum: 35 |