none
[MS-ADTS] Incorrect Ldap Ping Response Structure NETLOGON_SAM_LOGON_RESPONSE_EX (Section 7.3.1.9 ) RRS feed

  • Question

  • Hi,

    I am trying to understand the Ldap Ping Operation. Some Fields in the Second Extended Version Strucure of the Server's Response to the Ldap Ping Opearation(Section 7.3.1.9 NETLOGON_SAM_LOGON_RESPONSE_EX), like DnsForestName, DnsDomainName, DnsHostName which are Compressed with utf8 encoding are given wrong. I think there should be a null terminator.

    Can you Confirm it.... Please let me know i am wrong.

    Thanks

    Prasanna Kumar G


    @Prasanna_Kumar
    Monday, July 4, 2011 12:35 PM

Answers

  • Hi Rajesh:

    Compressed UTF-8 is different from UTF-8. The decompression algorithm is described in MS-SAMR section “7.3.7   Name Compression and Decompression”.  

     

    This compression is explained in RFC 1035 section “4.1.4. Message compression”.

     

    Here is a sample NetLogonSAMLogonResponseEX message (MS-ADTS section 7.3.1.9)

     

    17 00 00 00 FD 11 00 00 CF EF 67 67 95 71 5B 48 AB B0 AA FA E0 F4 0C 51 09 6E 77 74 72 61 64 65 72 73 04 6D 73 66 74 00 C0 18 0B 68 79 70 65 72 2D 76 2D 64 63 31 C0 18 09 4E 57 54 52 41 44 45 52 53 00 0B 48 59 50 45 52 2D 56 2D 44 43 31 00 00 17 44 65 66 61 75 6C 74 2D 46 69 72 73 74 2D 53 69 74 65 2D 4E 61 6D 65 00 C0 51 05 00 00 00 FF FF FF FF

     

    After the following messages fields:

     

    17 00 Opcode

    00 00 Sbz

    FD 11 00 00 Flags

    CF EF 67 67 95 71 5B 48 AB B0 AA FA E0 F4 0C 51 DomainGuid

     

    we have the compressed UTF-8 message

     

    09 6E 77 74 72 61 64 65 72 73 04 6D 73 66 74 00 C0 18 0B 68 79 70 65 72 2D 76 2D 64 63 31 C0 18 09 4E 57 54 52 41 44 45 52 53 00 0B 48 59 50 45 52 2D 56 2D 44 43 31 00 00 17 44 65 66 61 75 6C 74 2D 46 69 72 73 74 2D 53 69 74 65 2D 4E 61 6D 65 00 C0 51

     

    1. In the above message, the first byte is the length of the first label, 09
    2. First label is in UTF-8 which is 6E 77 74 72 61 64 65 72 73 (nwtraders)
    3. Length of next label 04
    4. Next labe 6D 73 66 74 (msft)
    5. Next byte is 00, which means end of the name. So DnsForstName= nwtraders.msft

     

    Next byte is C0. This is a special byte signifying an offset. The offset is contained in the next byte, 18. So going back 18 bytes from this one and which will be 09. We construct the name as above. Therefore, DnsDomainName is also nwtraders.msft.

     

    This is the type of compression that MS-ADTS is referring to. Instead of 16 bytes, DnsDomainName consumed only two bytes.

     

    The rest of the message can be decompressed the same way.

     

     Please let me know if it does not answer your question.

     


    Regards, Obaid Farooqi
    Tuesday, July 12, 2011 7:27 PM
    Owner

All replies

  • Hi Prasanna,

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

     


    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Monday, July 4, 2011 5:14 PM
    Moderator
  • Hi Prasanna:

    I'll help you with issue and will be in touch as soon as I have an answer.


    Regards, Obaid Farooqi
    Wednesday, July 6, 2011 10:00 PM
    Owner
  • Hi Prasanna:

    The fields that are compressed UTF-8 encoded, after decompression, are in a format where first byte represents the length of the label and following length number of bytes represent label in UTF-8 format. Label are not null terminated but a zero byte represents the end of the filed.

     

    So, for example, if DnsDomainName is contoso.com, the uncompressed representation of this would be

     

    <one byte representing length of contoso in UTF-8><bytes representing contoso in UTF-8><one byte representing the length of com in UTF-8><bytes representing com in UTF-8><zero byte to signal the end of name>

     

    I’ll file a bug to have this information documented in MS-ADTS.

     

    Please let me know if it does not answers your question.
    Regards, Obaid Farooqi
    Thursday, July 7, 2011 11:18 PM
    Owner
  • Is "Compressed UTF-8" is a different from normal UTF-8? If it is Can you point us to the specification that deals with how to decompress UTF-8?

    In that case, we should be able to read the compressed field from the stream first and then decompress. But we will not be able to read as we dont know the size of the field yet.

    Can you help?

     

     

    Tuesday, July 12, 2011 1:13 AM
  • Hi Rajesh:

    Compressed UTF-8 is different from UTF-8. The decompression algorithm is described in MS-SAMR section “7.3.7   Name Compression and Decompression”.  

     

    This compression is explained in RFC 1035 section “4.1.4. Message compression”.

     

    Here is a sample NetLogonSAMLogonResponseEX message (MS-ADTS section 7.3.1.9)

     

    17 00 00 00 FD 11 00 00 CF EF 67 67 95 71 5B 48 AB B0 AA FA E0 F4 0C 51 09 6E 77 74 72 61 64 65 72 73 04 6D 73 66 74 00 C0 18 0B 68 79 70 65 72 2D 76 2D 64 63 31 C0 18 09 4E 57 54 52 41 44 45 52 53 00 0B 48 59 50 45 52 2D 56 2D 44 43 31 00 00 17 44 65 66 61 75 6C 74 2D 46 69 72 73 74 2D 53 69 74 65 2D 4E 61 6D 65 00 C0 51 05 00 00 00 FF FF FF FF

     

    After the following messages fields:

     

    17 00 Opcode

    00 00 Sbz

    FD 11 00 00 Flags

    CF EF 67 67 95 71 5B 48 AB B0 AA FA E0 F4 0C 51 DomainGuid

     

    we have the compressed UTF-8 message

     

    09 6E 77 74 72 61 64 65 72 73 04 6D 73 66 74 00 C0 18 0B 68 79 70 65 72 2D 76 2D 64 63 31 C0 18 09 4E 57 54 52 41 44 45 52 53 00 0B 48 59 50 45 52 2D 56 2D 44 43 31 00 00 17 44 65 66 61 75 6C 74 2D 46 69 72 73 74 2D 53 69 74 65 2D 4E 61 6D 65 00 C0 51

     

    1. In the above message, the first byte is the length of the first label, 09
    2. First label is in UTF-8 which is 6E 77 74 72 61 64 65 72 73 (nwtraders)
    3. Length of next label 04
    4. Next labe 6D 73 66 74 (msft)
    5. Next byte is 00, which means end of the name. So DnsForstName= nwtraders.msft

     

    Next byte is C0. This is a special byte signifying an offset. The offset is contained in the next byte, 18. So going back 18 bytes from this one and which will be 09. We construct the name as above. Therefore, DnsDomainName is also nwtraders.msft.

     

    This is the type of compression that MS-ADTS is referring to. Instead of 16 bytes, DnsDomainName consumed only two bytes.

     

    The rest of the message can be decompressed the same way.

     

     Please let me know if it does not answer your question.

     


    Regards, Obaid Farooqi
    Tuesday, July 12, 2011 7:27 PM
    Owner