Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Good morning Tim - development has responded to the TDI - thank you very much for finding and reporting this - as well as for the opportunity for us to improve our implementation and documentation! Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. == The behavior exhibited on SMB1 regarding not receiving a sharing violation when doing a set of FileEndOfFileInformation when write sharing is disallowed is a bug in our server implementation. This is something we will pursue fixing, and the behavior does not exist for the FID-based set info in SMB1 or the set-info command in SMB2. We are investigating the best path to fix the issue and then update the documentation accordingly. It seems to exist inside the Path-based SetInfo path. == 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: Wednesday, December 16, 2009 2:05 PM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Indeed it is possible; NtQueryInformationFile with standard information levels does translate into passthrough levels on the wire (for SMB). But, as I mentioned, I am still working on the test code, and haven't invoked NtSetInformationFile or other functions yet; I am iterating on test cases to gather error return information (which is a subject always dear to everyone's heart!). Of course, named pipes, directories and the various flavors of junction points do complicate this somewhat... 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: Wednesday, December 16, 2009 1:59 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Thank you for the update! So if I understand what you're saying, it is possible for a windows app to cause the the smb client to send the passthrough levels over the wire using NtQueryInformationFile? -Tim On Dec 16, 2009, at 10:55 AM, Bill Wesse wrote: Good day Tim. I have just filed a Technical Documentation Issue (TDI) against the share mode issue requesting document update / guidance concerning SMB_INFO_PASSTHROUGH. My examination of our implementation indicates this situation should exist for all SET_PATH_INFORMATION information levels with SMB_INFO_PASSTHROUGH. I have not examined TRANS2_SET_FILE_INFORMATION or TRANS2_SET_FS_INFORMATION. [MS-SMB] and [MS-FSCC] provide no guidance concerning share circumvention for this or any other SMB_COM_TRANSACTION2 subcommand / information level with SMB_INFO_PASSTHROUGH, other than to say 'the client is requesting a native Windows NT operating system information level' ([MS-SMB] 6 Appendix A: Product Behavior, note 155). Also, I have nearly completed a test app (C++) to exercise these as much as possible - NtQueryInformationFile indeed uses SMB_INFO_PASSTHROUGH values. I intend to profile Windows behavior against the information levels, and will provide all of that to you as soon as I can. 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: Wednesday, December 09, 2009 10:56 AM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Tim, - thanks for the updated smbtorture. I have reproduced the truncated SMB error response - see frames 132 133 in the attached capture. I will create a new case for this, and begin debugging today (after verifying whether or not this happens against older Windows versions). Frame: Number = 133, Captured Frame Length = 102, MediaType = ETHERNET + Ethernet: Etype = Internet IP + (IPv4),DestinationAddress:[00-15-5D-04-7B-03],SourceAddress: [00-15-5D- + 04-7B-09] + Ipv4: Src = 192.168.0.10, Dest = 192.168.0.21, Next Protocol = TCP, + Packet ID = 1552, Total IP Length = 88 + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=47152, + PayloadLen=36, Seq=3281756320 - 3281756356, Ack=267797329, Win=510 + (scale factor 0x8) = 130560 + SMBOverTCP: Length = 32 - Smb: R - DOS OS Error, (124) INVALID_LEVEL Protocol: SMB Command: Transact2 50(0x32) + DOSError: DOS OS Error - (124) INVALID_LEVEL - SMBHeader:
[cifs-protocol] Status: SRX091201600038 [MS-ADTS] LDAPControl not applied on add
Good morning Nadya - I have created a Technical Document Issue (TDI) concerning your observation that ldap add operations ignore the LDAP_SERVER_SD_FLAGS_OID control. I have checked our implementation sources, which appears to support your conclusion. I expect we will be updating [MS-ADTS] 7.1.3.2 SD Flags Control (http://msdn.microsoft.com/en-us/library/cc223733(PROT.13).aspx ) accordingly. 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: Tuesday, December 01, 2009 9:13 AM To: 'Nadezhda Ivanova' Cc: cifs-proto...@samba.org Subject: 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.
Re: [cifs-protocol] Status: SRX091201600038 [MS-ADTS] LDAPControl not applied on add
Thanks Bill, Come to think of it, it does not make sense to support in on add, really, because when we create an object, we can just provide the part we need, and the rest will be defaulted. Its not necessary to use control for that. This resolves my issue. 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: Friday, December 18, 2009 5:55:29 PM GMT+0200 Europe;Athens Subject: Status: SRX091201600038 [MS-ADTS] LDAPControl not applied on add Good morning Nadya - I have created a Technical Document Issue (TDI) concerning your observation that ldap add operations ignore the LDAP_SERVER_SD_FLAGS_OID control. I have checked our implementation sources, which appears to support your conclusion. I expect we will be updating [MS-ADTS] 7.1.3.2 SD Flags Control (http://msdn.microsoft.com/en-us/library/cc223733(PROT.13).aspx ) accordingly. 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: Tuesday, December 01, 2009 9:13 AM To: 'Nadezhda Ivanova' Cc: cifs-proto...@samba.org Subject: 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
Re: [cifs-protocol] Structure of prefixMap over LDAP
Hi Andrew: Thanks for the clarification. I'll get back to you as soon as I have something concrete. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, December 15, 2009 1:39 AM To: Obaid Farooqi Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: Structure of prefixMap over LDAP On Tue, 2009-12-15 at 06:22 +, Obaid Farooqi wrote: Hi Andrew: In an effort to fully understand your goals, please explain what you are looking to achieve through the addition of documentation that defines the internal structure of the prefixMap attribute. As a start: The ability to generate a matching prefixMap attribute, should any client request it. The ability to verify prefixMap values over DRS and LDAP to confirm consistency. The ability to include prefixMap values in comparison tests we may make between AD and Samba4. An understanding of how the contents of this attribute interacts with msDs-intID and other prefix mapping functionality. Finally, I'm simply looking to ensure that the documentation set explains the format of every value (generated or otherwise) in AD, so we don't have to come back to this later. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] LDAP_SERVER_SD_FLAGS_OID control and search request
Hello, While testing ADUC I found that this tool is using the control LDAP_SERVER_SD_FLAGS_OID when requesting object with no attributes (ie. CN=Users,DC=home,DC=matws,DC=net) and expect to receive the nTSecurityDescriptor. Of course if you do not provide this control the nTSecurityDescriptor is not returned. I tested this behavior with w2k3r2 and it is how this server behave. Can you confirm that it's the expected behavior for this control and if possible can you document it if it's not already done. Regards. Matthieu. ___ 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
Bill, Thank you for diving into this issue and bringing clarity to how others should be implementing this. I sincerely appreciate your dilligence! -Tim On Dec 18, 2009, at 5:38 AM, Bill Wesse wrote: Good morning Tim - development has responded to the TDI - thank you very much for finding and reporting this - as well as for the opportunity for us to improve our implementation and documentation! Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. == The behavior exhibited on SMB1 regarding not receiving a sharing violation when doing a set of FileEndOfFileInformation when write sharing is disallowed is a bug in our server implementation. This is something we will pursue fixing, and the behavior does not exist for the FID-based set info in SMB1 or the set-info command in SMB2. We are investigating the best path to fix the issue and then update the documentation accordingly. It seems to exist inside the Path-based SetInfo path. == 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: Wednesday, December 16, 2009 2:05 PM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Indeed it is possible; NtQueryInformationFile with standard information levels does translate into passthrough levels on the wire (for SMB). But, as I mentioned, I am still working on the test code, and haven't invoked NtSetInformationFile or other functions yet; I am iterating on test cases to gather error return information (which is a subject always dear to everyone's heart!). Of course, named pipes, directories and the various flavors of junction points do complicate this somewhat... 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: Wednesday, December 16, 2009 1:59 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Thank you for the update! So if I understand what you're saying, it is possible for a windows app to cause the the smb client to send the passthrough levels over the wire using NtQueryInformationFile? -Tim On Dec 16, 2009, at 10:55 AM, Bill Wesse wrote: Good day Tim. I have just filed a Technical Documentation Issue (TDI) against the share mode issue requesting document update / guidance concerning SMB_INFO_PASSTHROUGH. My examination of our implementation indicates this situation should exist for all SET_PATH_INFORMATION information levels with SMB_INFO_PASSTHROUGH. I have not examined TRANS2_SET_FILE_INFORMATION or TRANS2_SET_FS_INFORMATION. [MS-SMB] and [MS-FSCC] provide no guidance concerning share circumvention for this or any other SMB_COM_TRANSACTION2 subcommand / information level with SMB_INFO_PASSTHROUGH, other than to say 'the client is requesting a native Windows NT operating system information level' ([MS-SMB] 6 Appendix A: Product Behavior, note 155). Also, I have nearly completed a test app (C++) to exercise these as much as possible - NtQueryInformationFile indeed uses SMB_INFO_PASSTHROUGH values. I intend to profile Windows behavior against the information levels, and will provide all of that to you as soon as I can. 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: Wednesday, December 09, 2009 10:56 AM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Tim, - thanks for the updated smbtorture. I have reproduced the truncated SMB error response - see frames 132 133 in the attached capture. I will create a new case for this, and begin debugging today (after verifying whether or not this happens against older Windows versions). Frame: Number = 133, Captured Frame Length = 102, MediaType = ETHERNET + Ethernet: Etype = Internet IP + (IPv4),DestinationAddress:[00-15-5D-04-7B-03],SourceAddress: [00-15-5D- + 04-7B-09] + Ipv4: Src = 192.168.0.10, Dest = 192.168.0.21, Next Protocol = TCP, + Packet ID = 1552, Total IP Length = 88 + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=47152, + PayloadLen=36, Seq=3281756320 - 3281756356, Ack=267797329, Win=510 + (scale factor 0x8) = 130560 + SMBOverTCP: Length = 32 - Smb: R - DOS OS
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
My pleasure - this was - and is - a very interesting topic! By the way, I will be continuing my study of SMB_INFO_PASSTHROUGH and the Nt*Info calls. I expect to post a blog entry on the 'Microsoft Open Specification Support Team Blog' (http://blogs.msdn.com/OpenSpecification/) sometime in January. 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: Friday, December 18, 2009 2:07 PM To: Bill Wesse Cc: Zachary Loafman; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Bill, Thank you for diving into this issue and bringing clarity to how others should be implementing this. I sincerely appreciate your dilligence! -Tim On Dec 18, 2009, at 5:38 AM, Bill Wesse wrote: Good morning Tim - development has responded to the TDI - thank you very much for finding and reporting this - as well as for the opportunity for us to improve our implementation and documentation! Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. == The behavior exhibited on SMB1 regarding not receiving a sharing violation when doing a set of FileEndOfFileInformation when write sharing is disallowed is a bug in our server implementation. This is something we will pursue fixing, and the behavior does not exist for the FID-based set info in SMB1 or the set-info command in SMB2. We are investigating the best path to fix the issue and then update the documentation accordingly. It seems to exist inside the Path-based SetInfo path. == 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: Wednesday, December 16, 2009 2:05 PM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Indeed it is possible; NtQueryInformationFile with standard information levels does translate into passthrough levels on the wire (for SMB). But, as I mentioned, I am still working on the test code, and haven't invoked NtSetInformationFile or other functions yet; I am iterating on test cases to gather error return information (which is a subject always dear to everyone's heart!). Of course, named pipes, directories and the various flavors of junction points do complicate this somewhat... 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: Wednesday, December 16, 2009 1:59 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Thank you for the update! So if I understand what you're saying, it is possible for a windows app to cause the the smb client to send the passthrough levels over the wire using NtQueryInformationFile? -Tim On Dec 16, 2009, at 10:55 AM, Bill Wesse wrote: Good day Tim. I have just filed a Technical Documentation Issue (TDI) against the share mode issue requesting document update / guidance concerning SMB_INFO_PASSTHROUGH. My examination of our implementation indicates this situation should exist for all SET_PATH_INFORMATION information levels with SMB_INFO_PASSTHROUGH. I have not examined TRANS2_SET_FILE_INFORMATION or TRANS2_SET_FS_INFORMATION. [MS-SMB] and [MS-FSCC] provide no guidance concerning share circumvention for this or any other SMB_COM_TRANSACTION2 subcommand / information level with SMB_INFO_PASSTHROUGH, other than to say 'the client is requesting a native Windows NT operating system information level' ([MS-SMB] 6 Appendix A: Product Behavior, note 155). Also, I have nearly completed a test app (C++) to exercise these as much as possible - NtQueryInformationFile indeed uses SMB_INFO_PASSTHROUGH values. I intend to profile Windows behavior against the information levels, and will provide all of that to you as soon as I can. 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: Wednesday, December 09, 2009 10:56 AM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE:
Re: [cifs-protocol] LDAP_SERVER_SD_FLAGS_OID control and search request
Hi Matthieu, I'll be helping you with this issue. Thanks and regards, Sebastian Canevari Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7849 e-mail: seba...@microsoft.com -Original Message- From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Friday, December 18, 2009 10:36 AM To: cifs-proto...@samba.org; Interoperability Documentation Help; p...@tridgell.net Subject: LDAP_SERVER_SD_FLAGS_OID control and search request Hello, While testing ADUC I found that this tool is using the control LDAP_SERVER_SD_FLAGS_OID when requesting object with no attributes (ie. CN=Users,DC=home,DC=matws,DC=net) and expect to receive the nTSecurityDescriptor. Of course if you do not provide this control the nTSecurityDescriptor is not returned. I tested this behavior with w2k3r2 and it is how this server behave. Can you confirm that it's the expected behavior for this control and if possible can you document it if it's not already done. Regards. Matthieu. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
