[cifs-protocol] Status: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
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)
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)
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
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
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