[cifs-protocol] [REG:110100459556182] [MS-BKRP] The behavior for BachuprKey RPC call issed against a RODC

Bryan Burgin bburgin at microsoft.com
Thu Oct 7 10:45:38 MDT 2010


Matthieu,

This regards the issue you raised at the IO Lab regarding what error code a MS-BKRP server implementation should return if called on a RODC.  You observed that the Microsoft MS-BKRP implementation in this scenario returns INVALID_PARAMETER.

I believe the documentation supports that behavior.  [MS-BKRP] 1.3.1 specifies that all writable DCs participate in MS-BKRP while no other machines (including RODCs) "support BackupKey Remote Protocol server functionality."  At [MS-BKRP] 3.1.4.1 BackuprKey (Opnum 0) ... Return Values, it says "[...]If the server does not support the pguidActionAgent value in the client request, the server MUST return ERROR_INVALID_PARAMETER (0x57) [...]".  Since RODCs MUST NOT "support BackupKey Remote Protocol server functionality". Returning ERROR_INVALID_PARAMETER is appropriate.

A client should not be talking a protocol to a server unless it knows that the server is a compliant implementation. As we have noted in 1.3.1, RODCs are not compliant implementations of MS-BKRP.  In a Microsoft Active Directory domain, the DC Locator functionality can be used to locate a writable DC. Therefore, MS-BKRP clients should use this to locate a compliant server. In non-Microsoft implementations, the client is expected to have some other method of locating a compliant server, as noted in Section 1.5:  "The client of the Backup Key RPC interface must implement a mechanism to determine a server to connect to, and any additional configuration required by this mechanism must be carried out."

I will close this issue as resolved.  But, if any additional follow-up is necessary, please contact me.

I have several other active MS-BKRP issues I'm working on for you, which I'll summarize in a separate e-mail.

Bryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20101007/466893d6/attachment.html>


More information about the cifs-protocol mailing list