[cifs-protocol] [REG:110092263101306] RE: backup protocol

[Matthieu Patou]

  On 24/09/2010 02:18, Matthieu Patou wrote:
>  On 23/09/2010 22:41, Hongwei Sun wrote:
>> Matthieu,
>>
>>    What I meant is that the guidGUID field in 
>> client-side-wrapped-secret structure is only dependent on the 
>> SubjectUniqueID field in the public key certificate received from 
>> server.   Actually the document states that all other fields (and 
>> extensions, if any) of the certificate are populated in 
>> implementation-specific ways and SHOULD be ignored by the client, but 
>> MS-BKRP still shows how these other fields are populated by the 
>> server in the Windows behavior note<5>.
>>
>>    I also took a look at the certificate you attached with your 
>> e-mail,  I got the following output using certutil:
>>
>>     X509 Certificate:
>>     Version: 3
>>     Serial Number: bd76df42470a008d473e743fa1dc8bbd
>>
>>     Subject Unique Id:
>>          0000  bd 8b dc a1 3f 74 3e 47  8d 00 0a 47 42 df 76 bd   
>> ....?t>G...GB.v.
>>
>>     We can see that SerialNumber and SubjectUniqueID  are in reversed 
>> order.  Does this mean that the SubjectUniqueID is in the same order 
>> as the GUID of certificate in AD as you refer to ?
> Yeah ! It's in the correct order (the same that you'll find on the 
> wire for the protocol)
>
>>     By the way, What is the GUID of certificate in AD ?  As I know, 
>> there is no GUID field in a X.509 certificate.  The RSA key pairs are 
>> saved in a LSA global secret named G$BCKUPKEY_guid on DC.   Is this 
>> the guid you are referring to ?
> Yeah I made a shortcut speaking about the guid part of the G$BCKUPKEY 
> (or the related entry in system subkey in the AD).
>>    If the certificate you attached is received from a Windows 
>> server,  we may need to update the Windows Behavior note<5>  to state 
>> that SerialNumber and subjectUnique Id is in reversed order, instead 
>> of identical.   Please confirm so I can follow up with a document 
>> update request.   Hopefully this should not affect interoperability.
> The cert comes from a w2k8r2 server, sure it's not too important, and 
> that's the things that gives me the clue that maybe you were reversing 
> more than 1 field in the whole protocol !
>
>
> Btw you might be please (at least I am) to know that I have a working 
> implementation of a torture test for the backup key remote protocol.
>
> I'm eager to clean this test and to start the code of the server part.
>
> While finishing the test I forgot to revert the bytes of the encrypted 
> secret, and I still received an answer from the server saying that's ok.
> I didn't recheck the specification right now but this didn't look like 
> the correct behavior.
>
>
Well this is in fact an error from me I confused between the smb call 
status (NT_STATUS_OK) and the status of the rpc WERR_xxx
We do have an error code, just time to time we don't have 
ERROR_INVALID_DATA but another one (with the same test suite.

I hope that I'll be able to show you this behavior this week so that you 
can see why is it like this.


Matthieu.

-- 
Matthieu Patou
Samba Team        http://samba.org