Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

[Nadezhda Ivanova]

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 
> To: Nadezhda Ivanova 
> Cc: 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: 'Nadezhd

Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)

[Bill Wesse]

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 
> To: Nadezhda Ivanova 
> Cc: 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 c

Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Tim Prouty]

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

[Bill Wesse]

Thanks!

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] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes

[Bill Wesse]

> 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

[Hongwei Sun]

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.com

[cid:image001.gif@01C81005.1792D9C0]   How breakthroughs begin. (tm)
<>___
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

[Tim Prouty]

On Dec 1, 2009, at 11:12 AM, Bill Wesse wrote:


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).


Bill, if it helps your repro I recently pushed an smbtorture test that  
demonstrates all of the issues mentioned in this thread: RAW-SFILEINFO- 
END-OF-FILE.  This is what I have been using to produce these traces.


-Tim
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol