none
[MS-OXCSTOR] RopLogon request buffer question RRS feed

  • Question

  • Hi,

    For certain clients our man-in-the-middle application is seeing undocumented OpenFlags bits in requests generated by Exchange 2013 server processes (and LoadGen, which I know is unsupported).

    The bit in question is 0x40, which changes the request and response buffer layouts.  It introduces a new DWORDS flags field between EssDnSize and EssDn, and bits of that field include other fields, not all of which I've worked out.

    Is there a possibility of getting more complete documentation on the RopLogin request and response buffers?

    Thanks,

    John Lowery

    Friday, October 26, 2012 7:42 PM

Answers

  • Hi John,

    The RopLogon LogonFlags byte in question affects the ROP request/response for Server to Server communication and is not in scope for the protocol documentation, which specifies Client to Server communication.

    Regards,

    Mark Miller | Escalation Engineer | Protocol Documentation Team

    Thursday, November 1, 2012 3:12 PM

All replies

  • Hi John,

    Thank you for your question. A member of the protocol documentation support team will respond to you soon.

    Regards,
    Vilmos Foltenyi - MSFT

    Friday, October 26, 2012 9:06 PM
  • Hi John,

    I will investigate this and follow up with you.

    Regards,

    Mark Miller | Escalation Engineer | Protocol Documentation Team

    Monday, October 29, 2012 5:23 PM
  • Vilmos, Mark

    Thank you.

    John

    Tuesday, October 30, 2012 12:30 AM
  • Well, that's embarrassing. I misstated my question. The element of the RopLogon request buffer I'm asking about is the (BYTE) LogonFlags, not the (DWORD) OpenFlags.  The bit identification is 0x40 as I stated previously.

    Sorry for the confusion,

    John

    Tuesday, October 30, 2012 8:35 PM
  • Hi John,

    The RopLogon LogonFlags byte in question affects the ROP request/response for Server to Server communication and is not in scope for the protocol documentation, which specifies Client to Server communication.

    Regards,

    Mark Miller | Escalation Engineer | Protocol Documentation Team

    Thursday, November 1, 2012 3:12 PM