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
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
