Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
Hi Bill, There are no issues with the LDAP_SERVER_SD_FLAGS_OID when sent with an LDAP modify - it behaves as documented. The issue here is that it does not seem to have any effect when sent with an LDAP add. Therefore I cannot send you a dump of the object before modification, because it hasn't been created yet :). Again, just to be sure we understand the issue: When I modify the descriptor of an existing object providing this control, the server behaves as documented, everything is in order. When I create a new object and provide the control, the control does not have any effect even though it is mentioned in the documentation that it operates on add as well. The new object's descriptor is created as though the control is not sent at all, and no error is returned. I do provide a security descriptor with the request, so its not the case where it is ignored... If you like, I can send you some script of the way I am creating the object, and a network capture? About the second question - I did look in ADTS for explanation, but I guess I missed it :). Thank a lot, I believe that answers the question. Regards, Nadya - Original Message - From: Bill Wesse bil...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@postpath.com Cc: cifs-proto...@samba.org cifs-proto...@samba.org Sent: Monday, November 30, 2009 9:51:11 PM GMT+0200 Europe;Athens Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169) Hello Nadya - here is the response information for your questions. The first question will undoubtedly need to be handled under a new service request. For the second one, please let me know if that answers everything (if so, I will consider SRX091119600169 resolved). === === Question: When I execute the test against a Win2008, domain functional level 2008, it actually fails. All of the fields of the provided security descriptor are applied, not only the ones specified by the control. Maybe there is some additional configuration and condition for the control to be taken into account? Response: I have examined our implementation of this, and find no relevant changes. I did not find anything involved with configuration that should affect the way security descriptor flags are treated. The LDAP server code handling for LDAP_SERVER_SD_FLAGS_OID is essentially unchanged from Windows 2003 through 2008R2. Could you please send me an 'dsacls CN=,...' dump of an updated object (before and after the update), as well as a network capture? I will create a new case upon receipt of that data. === === Question: I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in http://msdn.microsoft.com/en-us/library/aa367025(VS.85).aspx Using Controls Each extended control has a Criticality flag, represented by the ldctl_iscritical field of the LDAPControl structure. If this flag is set to TRUE, then the server will return a LDAP_UNAVAILABLE_CRIT_EXTENSION error code if the server does not support the request control when attempting an API call that includes the control. Using extended controls on a LDAP version 2 connection will also fail with this return code. Response: Behavior of an update operation when this control is specified is detailed in [MS-ADTS], section 7.1.3.2. If, during an update, no SD is provided and the control is provided, then the control is used to specify which (non-existent) parts of the (non-existent) SD are to be used in the update operation. Since that specifies no actual change in the update operation (that is, no new data for an SD is provided), the control is trivially being honored, and as such no error is returned, regardless of criticality. Essentially, the update operation (at least with respect to SDs) is a no-op. Explicitly, during an add operation, if no security descriptor is provided by the client, then specifying what parts of the security descriptor are relevant has no observable behavior, and is not an error. LDAP_CONTROL_REFERRALS (OID 1.2.840.113556.1.4.616) is never passed to the server, and the server neither parses nor understands it. It affects only the client side implementation of an LDAP client library. Specifically, it controls whether a client library should chase referrals returned by a DC or not. As this is client behavior only and not part of the server protocol, it does not fall under the scope of MS-ADTS. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Friday, November 20, 2009 3:25 PM To: 'Nadezhda Ivanova' Cc:
Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
Good morning Nadya - thanks for the feedback on SRX091119600169; I will archive that case. Concerning your next question, I have created the below case - and yes, please send me the script network capture. SRX091201600038 [MS-ADTS] LDAPControl not applied on add When I create a new object and provide the control, the control does not have any effect even though it is mentioned in the documentation that it operates on add as well. The new object's descriptor is created as though the control is not sent at all, and no error is returned. I do provide a security descriptor with the request, so it's not the case where it is ignored... Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Tuesday, December 01, 2009 4:18 AM To: Bill Wesse Cc: cifs-proto...@samba.org Subject: Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169) Hi Bill, There are no issues with the LDAP_SERVER_SD_FLAGS_OID when sent with an LDAP modify - it behaves as documented. The issue here is that it does not seem to have any effect when sent with an LDAP add. Therefore I cannot send you a dump of the object before modification, because it hasn't been created yet :). Again, just to be sure we understand the issue: When I modify the descriptor of an existing object providing this control, the server behaves as documented, everything is in order. When I create a new object and provide the control, the control does not have any effect even though it is mentioned in the documentation that it operates on add as well. The new object's descriptor is created as though the control is not sent at all, and no error is returned. I do provide a security descriptor with the request, so its not the case where it is ignored... If you like, I can send you some script of the way I am creating the object, and a network capture? About the second question - I did look in ADTS for explanation, but I guess I missed it :). Thank a lot, I believe that answers the question. Regards, Nadya - Original Message - From: Bill Wesse bil...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@postpath.com Cc: cifs-proto...@samba.org cifs-proto...@samba.org Sent: Monday, November 30, 2009 9:51:11 PM GMT+0200 Europe;Athens Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169) Hello Nadya - here is the response information for your questions. The first question will undoubtedly need to be handled under a new service request. For the second one, please let me know if that answers everything (if so, I will consider SRX091119600169 resolved). === === Question: When I execute the test against a Win2008, domain functional level 2008, it actually fails. All of the fields of the provided security descriptor are applied, not only the ones specified by the control. Maybe there is some additional configuration and condition for the control to be taken into account? Response: I have examined our implementation of this, and find no relevant changes. I did not find anything involved with configuration that should affect the way security descriptor flags are treated. The LDAP server code handling for LDAP_SERVER_SD_FLAGS_OID is essentially unchanged from Windows 2003 through 2008R2. Could you please send me an 'dsacls CN=,...' dump of an updated object (before and after the update), as well as a network capture? I will create a new case upon receipt of that data. === === Question: I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in http://msdn.microsoft.com/en-us/library/aa367025(VS.85).aspx Using Controls Each extended control has a Criticality flag, represented by the ldctl_iscritical field of the LDAPControl structure. If this flag is set to TRUE, then the server will return a LDAP_UNAVAILABLE_CRIT_EXTENSION error code if the server does not support the request control when attempting an API call that includes the control. Using extended controls on a LDAP version 2 connection will also fail with this return code. Response: Behavior of an update operation when this control is specified is detailed in [MS-ADTS], section 7.1.3.2. If, during an update, no SD is provided and the control is provided, then the control is used to specify which (non-existent) parts of the (non-existent) SD are to be used in the update operation. Since that specifies no actual change in the update operation (that is, no new data for an SD is provided), the control is trivially being honored, and as such no error is returned,
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
On Nov 30, 2009, at 6:06 PM, Tim Prouty wrote: Hi Bill, I have done some more investigation on this issue, particularly around doing a Trans2SetPathInfo() with the documented FileEndOfFileInformation (0x104) level. It returns what I would expect to be an acceptable error for an unknown info level. I have attached a trace that shows this being done against a win7 server, but I have a question about what the server is returning. The packets of interest are 39/40: 1. Packet 40 appears to have the WordCount and ByteCount truncated, making the packet smaller than normal minimum size of 35? Is this intended behavior that other servers should implement? Additionally a DOS Error is returned instead of a standard NT_STATUS error. MS-CIFS does say that a DOS error or an NT_STATUS error may be returned, but I don't see any indication in the documentation of when a DOS error should be returned instead of an NT_STATUS error. Is it possible to make this explicit in the docs or is this a case where it's purposefully left ambiguous? Thanks! -Tim Here's the pcap referenced in the previous email. trans2setpathinfo_against_win7_2.pcap Description: Binary data ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
1. Packet 40 appears to have the WordCount and ByteCount truncated, making the packet smaller than normal minimum size of 35? Is this intended behavior that other servers should implement? This is a surprise - I have never seen an SMB error packet without WordCount and ByteCount. I will take this into account once I get my test code running - which will be necessary to reproduce the missing WordCount / ByteCount (this looks like a bug to me, but I will have to dig deeper). Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Tuesday, December 01, 2009 12:34 PM To: Tim Prouty Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Nov 30, 2009, at 6:06 PM, Tim Prouty wrote: Hi Bill, I have done some more investigation on this issue, particularly around doing a Trans2SetPathInfo() with the documented FileEndOfFileInformation (0x104) level. It returns what I would expect to be an acceptable error for an unknown info level. I have attached a trace that shows this being done against a win7 server, but I have a question about what the server is returning. The packets of interest are 39/40: 1. Packet 40 appears to have the WordCount and ByteCount truncated, making the packet smaller than normal minimum size of 35? Is this intended behavior that other servers should implement? Additionally a DOS Error is returned instead of a standard NT_STATUS error. MS-CIFS does say that a DOS error or an NT_STATUS error may be returned, but I don't see any indication in the documentation of when a DOS error should be returned instead of an NT_STATUS error. Is it possible to make this explicit in the docs or is this a case where it's purposefully left ambiguous? Thanks! -Tim Here's the pcap referenced in the previous email. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMBv1 LockAndX return status on lock conflict
Steven, I am now working on this issue. I am wondering what program you ran to create the network trace attached in your e-mail. Is it Samba smbtorture ? If we can duplicate the behavior, it may be easier for us to debug it. Thanks! Hongwei From: Steven Danneman [mailto:steven.danne...@isilon.com] Sent: Wednesday, November 25, 2009 5:54 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMBv1 LockAndX return status on lock conflict Hello, When requesting a byte-range lock over SMBv1 on a range of a file which is already locked and thus will contend, the error code returned is inconsistent. The first attempt to acquire a held lock will return STATUS_LOCK_NOT_GRANTED. Subsequent requests will return STATUS_FILE_LOCK_CONFLICT. This seems as though it may be an error in the implementation of the SMBv1 protocol as the explanation of the two errors in MS-ERREF implies that STATUS_LOCK_NOT_GRANTED should always be returned in this circumstance: STATUS_LOCK_NOT_GRANTED A requested file lock cannot be granted due to other existing locks. STATUS_FILE_LOCK_CONFLICT A requested read/write cannot be granted due to a conflicting file lock. And in this same scenario the SMBv2 protocol always returns STATUS_LOCK_NOT_GRANTED. I aware this is a well known issue, as the Samba torture test demonstrating this behavior have existed for a number of years, but I haven't found any Microsoft documentation describing the semantics of this behavior. I've looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA. Furthermore, which error code is returned becomes even more complicated when additional lock requests are interspersed. For example the attached pcap against a W2K8R2 server shows: 1) Two file handles opened to the same file 0x400b, 0x400c 2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock on range 100 - 110 3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held range and receiving STATUS_LOCK_NOT_GRANTED 4) Packet 33-44: Again requesting the same held range and receiving STATUS_FILE_LOCK_CONFLICT 5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and receiving the same pattern of errors 6) Packet 55-64: Requesting a lock on the previous range, 100-110, and now having the response be reset back to STATUS_LOCK_NOT_GRANTED I'd like to have some documentation of the algorithm for determining which error to return based on the state of existing locks, or history of previously requested locks. Thanks, Steven Danneman | Software Development Engineer Isilon SystemsP +1-206-315-7500 F +1-206-315-7501 www.isilon.comhttp://www.isilon.com [cid:image001.gif@01C81005.1792D9C0] How breakthroughs begin. (tm) inline: image001.gif___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
