[cifs-protocol] Status: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header

2009-12-10 Thread Bill Wesse
Good morning Tim.

I have performed a code study of our SMB server implementation, and can assure 
you that SMB response error processing is rather complex (which is no doubt not 
a surprise to you). A considerable number of specific SMB command responses, as 
well as client SMB_DIALECT levels come into play. Determining the level of 
detail we can provide is outside of my purview, so I have filed a Technical 
Document Issue (TDI) concerning error handling per your request (text included 
below).

In my travels, I did notice that the [MS-CIFS-Preview] document, 2.2.2.4 'SMB 
Error Classes and Codes', as well as individual command sections provide a good 
start on error codes - but does not completely answer your question.

[MS-CIFS-Preview]: Common Internet File System (CIFS)
http://msdn.microsoft.com/en-us/library/ee794904.aspx

Question:

MS-CIFS does say that a DOS error or an NT_STATUS error may be returned for a 
given command, 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?

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 3:31 PM
To: 'Tim Prouty'
Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net
Subject: RE: New case: SRX091209600095 Trans2SetPathInfo() returns truncated 
SMB header

Tim - I have verified that Windows 2000 through Windows 2008 R2  Windows 7 all 
behave the same way - and return the invalid level DOSError 124. This is 
definitely by design, as is the omission of WordCount and ByteCount.

What [CIFS] and [MS-SMB] do not detail very well is how error codes are cooked 
before return.

It is true that the request header.Flags2 field has SMB_FLAGS2_NT_STATUS set - 
which one would expect to force an NT Status return code. There are cases where 
this is not going to occur - Trans2SetPathInfo() with an invalid level being 
one of them.

There are many #defined for constants and macros in cifs.h (from the Windows 
Driver Kit [WDK-7]) noted in the below description - and I have included the 
relevant ones below.

Before I can go further with a more global description of SMB error code 
'cooking', I will file a TDI to request that.

For the moment, here is what's up with Trans2SetPathInfo():

In this case - an SMB_COM_TRANSACTION2 (and I think as a consequence of the 
history of SMB) requesting TRANS2_SET_PATH_INFORMATION (0x06) with an invalid 
level per [CIFS], such as SMB_SET_FILE_END_OF_FILE_INFO (0x104) - our 
implementation sets the internal SMB Status to STATUS_OS2_INVALID_LEVEL 
(cifs.h), which is '0xC098F07C'.

This is processed as follows before appearing on the wire:

If the SrvIsSrvStatus(Status) check passes (which it should, in this case, per 
the included #defines from cifs.h), the error code is truncated using the 
SrvErrorClass(Status) macro (also from cifs.h), and the error class is set to 
SMB_ERR_CLASS_DOS (0x1). The SMB_FLAGS2_NT_STATUS bit is cleared in the 
response header.Flags2 field, and the return context is marked to omit 
WordCount and ByteCount.

The error equates to '01 00 7C 00' :

DOSError.ErrorClass (0x0001,   1d) : SMB_ERR_CLASS_DOS
DOSError.Error  (0x007C, 124d) : SrvErrorCode(STATUS_OS2_INVALID_LEVEL)

[CIFS]
A Common Internet File System (CIFS/1.0) Protocol Preliminary Draft
http://www.microsoft.com/about/legal/protocols/BSTD/CIFS/draft-leach-cifs-v1-spec-02.txt

[WDK-7]
Windows Driver Kit Version 7.0.0
http://www.microsoft.com/downloads/details.aspx?FamilyID=2105564e-1a9a-4bf4-8d74-ec5b52da3d00displaylang=en

[WDKI MSDN]
Windows Driver Kit
http://msdn.microsoft.com/en-us/library/aa972908.aspx

==
winerror.h

#define ERROR_INVALID_LEVEL  124L

==
cifs.h

#define SrvIsSrvStatus(Status) \
( ((Status)  0x1FFF) == SRV_STATUS_FACILITY_CODE ? TRUE : FALSE )

#define SrvErrorClass(Status) ((UCHAR)( ((Status)  0xF000)  12 ))

#define STATUS_OS2_INVALID_LEVEL (NTSTATUS)(SRV_OS2_STATUS | 
ERROR_INVALID_LEVEL)

#define SrvErrorCode(Status) ((USHORT)( (Status)  0xFFF) )

#define SMB_ERR_CLASS_DOS (UCHAR)0x01

#define SRV_STATUS_FACILITY_CODE   0x0098L
#define SRV_SRV_STATUS(0xC000L | SRV_STATUS_FACILITY_CODE)
#define SRV_DOS_STATUS(0xC0001000L | SRV_STATUS_FACILITY_CODE)
#define SRV_SERVER_STATUS (0xC0002000L | SRV_STATUS_FACILITY_CODE)
#define SRV_HARDWARE_STATUS   (0xC0003000L | SRV_STATUS_FACILITY_CODE)
#define SRV_WIN32_STATUS  (0xC000E000L | SRV_STATUS_FACILITY_CODE)
#define SRV_OS2_STATUS   

Re: [cifs-protocol] Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)

2009-12-10 Thread Bill Wesse
Good day Tridge! I have included below the answer I provided on November 13. I 
will archive the case next Monday (December 14) if I do not hear from you; if 
necessary, we can reopen the case.

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



From: Bill Wesse
Sent: Friday, November 13, 2009 1:11 PM
To: 'tri...@samba.org'
Cc: 'cifs-proto...@samba.org'; 'h...@highlandsun.com'
Subject: Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on 
rDN size in AD)

The length of a delete-mangled RDN may indeed exceed rangeUpper, due to the 
additional delete-mangle decoration.

I should first note that the delete-mangled RDN format contains a '\0A' 
character - not a '\0'. Perhaps this is a typo in your email?

\0A is a character not allowed in Active Directory names, per [MS-ADTS] 
3.1.1.5.1.2 - and is certainly a handy way to verify whether or not a name has 
been mangled (a.k.a. strchr(pszRDN, (int)0x0a) ).

The format is, of course, noted in [MS-ADTS] 3.1.1.5.5 , like 
objectName\0ADEL:dashed_string_objectGUID. As noted in [MS-ADTS] 3.1.1.5.1.2. 
the maximum RDN length is 255; it is further constrained to 64 ([MS-ADA1] 2.110 
Attribute cn, rangeUpper: 64).

That said, the length of a delete-mangled RDN can be up to 105 characters (not 
including the terminating NUL character): {rangeUpper:64} + {0x0A:1} + 
{'DEL:':4} + {dashed-string-Guid:36}.

[MS-ADTS] 3.1.1.5.1.2 also notes that Naming constraints are not enforced for 
replicated updates., so the additional length of a delete-mangled RDN will 
replicate properly.

I have filed a TDI against [MS-ADTS] section 3.1.1.5.5 Delete Operation to have 
this annotated.

References:

[MS-ADTS]: Active Directory Technical Specification

3.1.1.5.1.2 Naming Constraints

During an originating update of the Add, Modify, and Modify DN operations, the 
server validates the following naming constraints. Unless otherwise specified, 
the server returns LDAP error namingViolation if a naming constraint is not met.

o The RDN must not contain a character with value 0xA.

o The RDN must not contain a character with value 0x0; otherwise, the server 
SHOULD return LDAP error invalidDNSyntax. However, if the DC functional level 
is DS_BEHAVIOR_WIN2000, the server will not return an error.

o The DN must be compliant with [RFC2253].

o The RDN size must be less than 255 characters.

Naming constraints are not enforced for replicated updates.

3.1.1.5.5 Delete Operation
...
In most cases, upon deletion, a tombstone, deleted-object, or recycled-object 
is moved into the Deleted Objects container of its NC; for exceptions see 
section 3.1.1.5.5.6. The RDN of the object is changed to a delete-mangled 
RDN-an RDN that is guaranteed to be unique within the Deleted Objects 
container. If O is the object that is deleted, the delete-mangled RDN is the 
concatenation of O!name, the character with value 0x0A, the string DEL:, and 
the dashed string representation ([RFC4122] section 3) of O!objectGUID. A 
delete-mangled DN is a DN such that the leaf RDN is a delete-mangled RDN.

==
Question:

From: tri...@samba.org [mailto:tri...@samba.org]
Sent: Monday, November 09, 2009 6:58 PM
To: Hongwei Sun
Cc: cifs-proto...@samba.org; h...@highlandsun.com
Subject: RE: limits on rDN size in AD ?

Hi Hongwei,

We're back to the old question of rDN size limits again!

I just got a DRS replication reply from w2k8-r2 with a CN that has a length 
larger than 64. So I suspect that things are a bit more complex than what we'd 
discussed before.

The object was:

  
CN=89532b80-09fe-445e-afef-965c0d7f7d15\0ADEL:462902b4-1824-4f02-8956-9f934f64fa01,CN=Deleted
 Objects,CN=Configuration,DC=vsofs8,DC=com

which gives a length of 80.

Are we perhaps supposed to interpret the \0 as a termination character for the 
purposes of this length constraint? (note that this is a \ followed by a 0, not 
a nul byte).

Or perhaps deleted objects are special in their constraints in some way?

Cheers, Tridge

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


Re: [cifs-protocol] Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)

2009-12-10 Thread Bill Wesse
Good day Tridge! I have included below the answer I provided on October 26. I 
will archive the case next Monday (December 14) if I do not hear from you; if 
necessary, we can reopen the case.

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: Monday, October 26, 2009 1:35 PM
To: 'tri...@samba.org'
Cc: 'cifs-proto...@samba.org'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 
7.3.3.2 DS_FLAG option bits)

Good morning Tridge! As I previously noted, Domain Controller LDAP Ping 
handling will ignore anything in the filter other than the documented elements 
([MS-ADTS] 7.3.3 LDAP Ping): DnsDomain, Host, User, AAC, DomainSid, DomainGuid 
and NtVer.

Concerning [MS-ADTS] 7.3.3.2 (Domain Controller Response to an LDAP Ping), the 
statements about the DS_DNS_CONTROLLER_FLAG, DS_DNS_DOMAIN_FLAG  
DS_DNS_FOREST_FLAG bits have been removed, since they are not (and have never 
been) set in our implementation.





Please see the attached '[MS-ADTS]_Changes.pdf'; there are several other 
changes pending in 7.3.3.2.

We have no plans to change LDAP Ping response behavior; this is not unexpected, 
since there is no guarantee that a given server deployment would have any 
applicable hotfix or service pack installed. So the flag bits would be 
undependable.

Of course, the 'complete' DOMAIN_CONTROLLER_INFO can be obtained via 
DsGetDcName as well as the IDL_DRSDomainControllerInfo method (links are 
included below for the sake of completeness).

Please let me know if this answers your question satisfactorily; if so, I will 
consider the case resolved. Thanks for helping us improve our documentation.

==
References:

http://msdn.microsoft.com/en-us/library/ms675983.aspx
DsGetDcName Function

http://msdn.microsoft.com/en-us/library/ms675912.aspx
DOMAIN_CONTROLLER_INFO Structure

[MS-DRSR]: Directory Replication Service (DRS) Remote Protocol Specification
4.1.5.3 Examples of the IDL_DRSDomainControllerInfo Method
4.1.5.3.3 Server Response
http://msdn.microsoft.com/en-us/library/cc228357.aspx

4.1.5.1.11 DS_DOMAIN_CONTROLLER_INFO_W
http://msdn.microsoft.com/en-us/library/cc228351.aspx


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: Monday, October 19, 2009 10:44 AM
To: 'tri...@samba.org'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 
7.3.3.2 DS_FLAG option bits)

Good morning Tridge - just an FYI - LDAP Ping handling will ignore anything 
other than the documented elements (([MS-ADTS] 7.3.3: elements: DnsDomain, 
Host, User, AAC, DomainSid, DomainGuid and NtVer).

The response to the TDI is still pending. I will advise you as details are 
available.

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, October 13, 2009 10:15 AM
To: 'tri...@samba.org'
Subject: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 
DS_FLAG option bits)

Good morning Tridge. My findings indicate that LDAP Ping handling on the DC 
will consider only the documented elements ([MS-ADTS] 7.3.3: elements: 
DnsDomain, Host, User, AAC, DomainSid, DomainGuid and NtVer).

I am still waiting for a response on the TDI.
 
Please note I am out of the office for the next several days, due to illness. I 
will keep current on any incoming email from you, as well as developments on 
the TDI. If needed, we can temporarily reassign the case to someone else on my 
team.

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: Monday, October 05, 2009 10:11 AM
To: 'tri...@samba.org'
Subject: RE: Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 
7.3.3.2 DS_FLAG option bits)

You're welcome - I expect to begin a debug on 2008 R2 concerning this later 
today, or tomorrow; I can't predict whether or not modifying the search filter 
to would influence the result (I will look into a modified test to check this). 
Certainly, one would expect the DS_DNS_FOREST_FLAG to be set in the response, 
since DnsForestName is present (and so on).

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 

Re: [cifs-protocol] New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header

2009-12-10 Thread Tim Prouty

On Dec 9, 2009, at 12:31 PM, Bill Wesse wrote:


This is processed as follows before appearing on the wire:

If the SrvIsSrvStatus(Status) check passes (which it should, in this  
case, per the included #defines from cifs.h), the error code is  
truncated using the SrvErrorClass(Status) macro (also from cifs.h),  
and the error class is set to SMB_ERR_CLASS_DOS (0x1). The  
SMB_FLAGS2_NT_STATUS bit is cleared in the response header.Flags2  
field, and the return context is marked to omit WordCount and  
ByteCount.


Hmm, I didn't know that there are cases where the WordCount and  
ByteCount are omitted.  Is this the case for all DOS errors?  Is it  
possible to document the cases when they are omitted?  As it is there  
is samba client code that detects an omitted WordCount/ByteCount in  
this situation as an error, so if this is correct server behavior  
we'll need to update the client.


Thank you for your detailed investigation!

-Tim

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


Re: [cifs-protocol] FW: Group Policy questions

2009-12-10 Thread Sebastian Canevari
Hi Matthieu,

With regards of the OI and CI flags, we always set those flags on if the ACE 
type is any of the following 3 types:

ACCESS_ALLOWED_ACE_TYPE
ACCESS_DENIED_ACE_TYPE
SYSTEM_AUDIT_ACE_TYPE

This is hardcoded.

I'll provide you with the answer to your other question soon.

Thanks and regards,

Sebastian


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 04, 2009 3:32 PM
To: Sebastian Canevari
Cc: Hongwei Sun; cifs-proto...@samba.org; p...@tridgell.net
Subject: Re: FW: [cifs-protocol] Group Policy questions

On 04/12/2009 23:00, Sebastian Canevari wrote:
 Hi Matthieu,

 Just a clarification to ask you for:

 We are discussing with Hongwei and the PGs  if it is that you are seeing GPMC 
 expect the inheritance to happen OR if it is that you are dumping the ACLs 
 and seeing the flags always.


What I see if when I dump the SD of the files modified by GPMC after it realize 
that there was a mismatch between the SD in AD and the SD in the Policy folder.
Note: it was with XP sp2 as a client.

Matthieu.
 Please clarify because we were under the impression that we had to look into 
 the client tool, but if the latter is what your question means, then we need 
 to look into AD.

 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: Sebastian Canevari
 Sent: Thursday, December 03, 2009 4:18 PM
 To: 'Matthieu Patou'; cifs-proto...@samba.org; Interoperability
 Documentation Help; p...@tridgell.net
 Subject: RE: FW: [cifs-protocol] Group Policy questions

 Hi Matthieu,

 We are still actively working on this and I do have the PG engaged.

 Please accept my apologies if we are delaying a little longer than expected. 
 I guess we can say that the holidays affected the timing a little without 
 trying to use that as an excuse.

 I'll keep you posted as soon as I have news.

 Thanks and regards,

 Sebastian


 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: Thursday, December 03, 2009 4:05 PM
 To: Sebastian Canevari; cifs-proto...@samba.org; Interoperability
 Documentation Help; p...@tridgell.net
 Subject: Re: FW: [cifs-protocol] Group Policy questions

 Hello sebastian


 And last but not least question, it seems that GPMC whats to have OI and CI 
 flags on every ACL entries is it due to the presence of the 
 SDDL_AUTO_INHERITEDcontrol in the SDDL  ?


 Any news on this ?
 More exactly my question is why this flag appear on each ACE ?

 Also do you plan to document this in a WSPP document ?

 Regards.
 Matthieu.
On 13/11/2009 02:40, Sebastian Canevari wrote:

 Hi Matthieu,


 I'll be working with you on these questions.

 I will keep you updated.

 Thanks!

 Sebastian



 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: Hongwei Sun
 Sent: Wednesday, November 11, 2009 9:35 PM
 To: Matthieu Patou
 Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari
 Subject: RE: FW: [cifs-protocol] Group Policy questions

 Matthieu,

  I double checked the logic and your assumption is right.   The return 
 value for SYSVOL access mask should be assigned to the input value first.   
 For your other questions,  since I am out of office , Sebastian will work on 
 them and let you know.

 Thanks!

 Hongwei

 -Original Message-
 From: Matthieu Patou [mailto:mat+informatique.sa...@matws.net]
 Sent: Wednesday, November 11, 2009 12:22 AM
 To: Hongwei Sun
 Cc: cifs-proto...@samba.org; p...@tridgell.net
 Subject: Re: FW: [cifs-protocol] Group Policy questions

 Hello Hongwei,

 I've been working on the translation function, I am getting quite similar 
 ACL right now but I have some remarks and questions.

 The pseudo code contains this:

 DSAccessMask as Input;
 SYSVOLAccessMask as Output;

 SYSVOLAccessMask=  STANDARD_RIGHTS_ALL ;

 I have impression that it should be

 DSAccessMask as Input;
 SYSVOLAccessMask as Output;

 SYSVOLAccessMask  = DSAccessMask;
 SYSVOLAccessMask=  STANDARD_RIGHTS_ALL ;


 Maybe the third line is implied in this kind of pseudo code.

 Also it seems to me that GPMC is discarding any ACL of type 
 ACCESS_ALLOWED_OBJECT_ACE (OA) and also everything related to SID 
 SID_BUILTIN_PREW2K (RU).

 And last but not least question, it seems