[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