Created attachment 8034 [details] Keytab to decrypt the trace ldp sends sd_flags control with a control value on 5 bytes, the control parser only reads 4 bytes and of course reads a completely bogus value. As the specification says that it's on 4 bytes one of the options should be to reject the request if the integer is longer. The other is only to parse the lower four bytes.
Created attachment 8035 [details] Trace from ldp
On packet 34 we can see the request from ldp with more than 32 bit integer as the control value.
I think we should try to fix this before the release if possible
Created attachment 8107 [details] Screenshot of the packet description
Created attachment 8108 [details] New trace with kerberos and ldap packets
Sorry Matthieu, but the control structure is fine according to spec and the Ldap server code looks correct and should decode it properly. The value sent by ldp in this case is '4' 4 is: DACL_SECURITY_INFORMATION (DSI) according to MS-ADTS: 3.1.1.3.4.1.11 From what I seem to read in the code what appears to be happening is that our code simply does not handle properly any case where flags are 0 or 0x0F Any time windows sends us only one of the bits of info and not a whole SD we replace the whole SD with the partial info, corrupting the SD in the process. (I am reading code at 2.20Am so take this with a grain of salt :-)
And fo course 2 seconds after I hit 'enter' Matthieu correctly points me at descr_handle_sd_flags() :-)
After talking to simo he proved me that this one is not a bug
After talking to simo he proved me that this one is not a bug as the ldap part is parsing the control correctly. The problem is down the stack and I think the bug https://bugzilla.samba.org/show_bug.cgi?id=9279 is tracking it. I propose to close this bug and focus on 9279
The problem is different... The server closes the connection (TCP FIN,ACK) after it is idle for 36 seconds. See frame 88 in sd_corruption2. In frame 93 the client sends the LDAP modify 1 minute and 21 seconds later and gets (TCP,RST) from the server. Where do you see a problem, here? The idle timeout of 36 seconds is strange, our default is 900 seconds. See ldapsrv_load_limits(), do you have configured MaxConnIdleTime?
Matthieu, could you reproduce it with a capture(keytab) and a level 10 log file and an ldbsearch --show-binary ldif before and after the change?
(In reply to comment #11) > Matthieu, could you reproduce it with a capture(keytab) and a level 10 log file > and an ldbsearch --show-binary ldif before and after the change? Please also include the ldif with base64 output.