Re: [cifs-protocol] STATUS_OS2_INVALID_LEVEL
Thanks for the heads up Christopher - you are totally correct in saying my comments on the complexity of NT platform SMB error returns were meant to be 'polite understatements' (especially that pesky flipped response SMB_FLAGS2_NT_STATUS bit, not to mention the 'occasionally optional' WordCount and ByteCount absence from transact2 responses). I will shortly forward your email to concerned internal parties... I have no doubt a complete rundown of all the exceptions to the rule would be quite valuable to our respective organizations and customers - figuring what to do in response to a 'surprise' error value classifies as yet another 'polite understatement'. I won't rule out the possibility of (my team) providing supplemental content concerning this, in case the documents aren't the optimal place for the info - I hate to state the obvious, but a complete WB description of the above for all NT/SMB (or just transact2) would be pretty big. There I go again. Another understatement. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.com Tel:+1(980) 776-8200 Cell: +1(704) 661-5438 Fax:+1(704) 665-9606 -Original Message- From: Christopher R. Hertel [mailto:c...@ubiqx.mn.org] Sent: Wednesday, January 13, 2010 5:17 PM To: tim.pro...@isilon.com; Jeremy Allison; p...@tridgell.net; cifs-proto...@samba.org Cc: Gary Shang; Bill Wesse; José Rivera Subject: STATUS_OS2_INVALID_LEVEL Tim, et. al., I just caught wind of a ticket opened internally at Microsoft HQ that was generated by a question you asked. As a result of this ticket, a change was recommended for [MS-CIFS] that would have caused a good deal of trouble so I am sending this out in an effort to clarify things a bit. [MS-CIFS] states this: SMB_FLAGS2_NT_STATUS (0x4000): If this bit is set in a client request, the server MUST return errors as 32-bit NTSTATUS codes in the response. If it is clear, the server MUST return errors in SMBSTATUS format. That's the way it *should* work. In fact, there is a whole set of 32-bit status codes that are wire-identical to the DOSOS/2 style Class/Code pairs. For example, STATUS_OS2_INVALID_LEVEL is defined as 0x007C0001, which is exactly the same (on the wire) as ERRDOS/ERRunknownlevel (0x01/0x007C). Gary: I have had a little more time to look at this and consider the implications of the capture Tim provided. My thoughts: * Windows 7 SHOULD be returning a 32-bit code. The code SHOULD be STATUS_OS2_INVALID_LEVEL which, as stated above, is identical to ERRDOS/ERRunknownlevel. That is, The value in the Status field returned by Windows 7 is correct no matter how you cut it. * Windows 7 SHOULD NOT be clearing the SMB_FLAGS2_NT_STATUS bit in the response. (Gary: This is where your proposed change was correct.) + Note that [MS-CIFS] covers Windows NT only, so we need to see if NT changes this bit as well. If so, then we add a WBN in [MS-CIFS]. If not, then the WBN belongs in [MS-SMB]. Bill W's comment in the earlier thread, stating that the status code management in NT is complex, is a polite understatement. We spent months trying to figure this out. In [MS-CIFS], you will find several 32-bit status codes defined that are wire-identical to old-style Class/Code pairs. * STATUS_INVALID_SMB * STATUS_SMB_* * STATUS_OS2_* ...all of the above are wire identical whether they are viewed as NTSTATUS or SMBSTATUS. Chris -)- PS. I somehow got kicked off of the cifs-protocol list a while back and can't seem to get re-registered so please make sure I'm in the CC list if you respond. -- Implementing CIFS - the Common Internet FileSystem ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- c...@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/-)- c...@ubiqx.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always present
Good morning once again Kamen! Here is what’s up with the TDI… Your comment: Btw, one interesting observation during my tests – adding ‘msDS-IntId’ on classSchema object passes nicely during object creation. After that, trying to modify this attribute value leads to “CONSTRAINT_VIOLATION”. And I am wondering – what is the meaning of ‘msDS-IntId’ when used in a classSchema object Response: Essentially, this means that a client cannot modify the objectCategory of an instance of a base schema class (the DSA can do this on its own behalf only). On another note: [MS-ADTS] 3.1.1.2.3 Attributes (http://msdn.microsoft.com/en-us/library/cc223202(PROT.13).aspx) says the DC returns LDAP error unwillingToPerform on any attempt to specify msDS-IntId on an Add operation. I have alerted those concerned with the TDI to this; the response to your main question (…a ‘steady’ rule when to create ‘msDS-IntId’ value for an attribute in the schema) is still pending. Thanks for your patience. Regards, Bill Wesse MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 Email: bil...@microsoft.commailto:bil...@microsoft.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 From: Bill Wesse Sent: Thursday, December 31, 2009 8:41 AM To: 'Kamen Mazdrashki' Cc: 'p...@tridgell.net'; 'abart...@samba.org'; 'cifs-proto...@samba.org' Subject: RE: Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always present Good morning Kamen – I neglected to advise you I filed a Technical Documentation Issue (TDI) concerning the msDS-IntId attribute. This is still under investigation by our document developers, and I will advise you as soon as some results are forthcoming. Thanks for your patience! 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: Wednesday, December 16, 2009 9:52 AM To: 'Kamen Mazdrashki' Cc: p...@tridgell.net; abart...@samba.org; cifs-proto...@samba.org Subject: RE: Status: SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always present (SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation) Thanks for the update Kamen – I have created the following case to track our work. Unless you think otherwise, I will archive the old case (SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation)). SRX091216600027 [MS-ADTS] 3.1.1.2.3 msDS-IntId not always present I expect to be able to begin work later today – or by tomorrow morning at the latest. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Tuesday, December 15, 2009 9:08 PM To: Bill Wesse Cc: p...@tridgell.net; abart...@samba.org; cifs-proto...@samba.org Subject: RE: Status: SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation Hi Bill, Finally I have a “msDS-IntId” attribute. You can find the test in “source4/lib/ldb/tests/python/ldap_schema.py” python script. You can execute the script from ‘source4’ directory as follows: lib/ldb/tests/python/ldap_schema.py -UAdministrator%password w2k8 This test is only in my branch thus you can download it from (sorry for the inconvenience): http://repo.or.cz/w/Samba/kamenim.git/snapshot/1de38d8251c6df7fb23d68033f57c1f8f53bcded.tar.gz According to MS-ADTS http://msdn.microsoft.com/en-us/library/cc223202%28PROT.13%29.aspx, msDS-IntId is “Present on attributeSchemahttp://msdn.microsoft.com/en-us/library/cc221662%28PROT.13%29.aspx objects added when forest functional level is DS_BEHAVIOR_WIN2003 or greater with FLAG_SCHEMA_BASE_OBJECT not present in systemFlagshttp://msdn.microsoft.com/en-us/library/cc220919%28PROT.13%29.aspx”. However, when running the test against w2k8 there are lot of attributes that does not obey this rule. Please see attached file “w2k8_msDS-IntId.txt”. At first I thought that those attributes has attributeIDs that can be encoded/decoded using ‘default prefixMap’. After examining the list though, it turns out this is not the case for majority of those attributes. Please see attached file “not_in_default_prefixMap.txt” for a list of those attributes. Perhaps I am misunderstanding the documentation? I need a ‘steady’ rule when to create ‘msDS-IntId’ value for an attribute in the schema. Is there any other rule to be applied? I need to note here that those attributes comes from w2k8 default provisioning. Any newly added attributes strictly obey the abovementioned rule (I found no way to add an attribute with FLAG_SCHEMA_BASE_OBJECT flag set though). CU, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO
Re: [cifs-protocol] Structure of prefixMap over LDAP
On Thu, 2010-01-14 at 18:26 +, Obaid Farooqi wrote: Hi Andrew: Please let me know if the following answers your question. If yes, I'll consider this issue resolved. I'm waiting on Kamen to implement this in Samba4 to verify the resolution. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] STATUS_OS2_INVALID_LEVEL
Bill Wesse wrote: Thanks for the heads up Christopher - you are totally correct in saying my comments on the complexity of NT platform SMB error returns were meant to be 'polite understatements' (especially that pesky flipped response SMB_FLAGS2_NT_STATUS bit, not to mention the 'occasionally optional' WordCount and ByteCount absence from transact2 responses). The thing about the flipped bit: The SMB_FLAGS2_NT_STATUS bit is *NOT* cleared by Windows NT when sending one of the suspect error codes. NT, that is, is saying that it's a 32-bit code. We've documented these codes as such in [MS-CIFS]. It makes it MUCH easier to document the entire problem. Basically, though, what we're dealing with is a 20-year-old kludge with no clear fix. It simply needs to be explained so that implementers can work with it. I will shortly forward your email to concerned internal parties... I'm available internally as v-chhert. Yeah... I'm a double agent! :) Say hello to Will and Darryl for me. I have no doubt a complete rundown of all the exceptions to the rule would be quite valuable to our respective organizations and customers It's difficult to get the documentation right but it can be explained and doing so would probably help you guys out. - figuring what to do in response to a 'surprise' error value classifies as yet another 'polite understatement'. :) I won't rule out the possibility of (my team) providing supplemental content concerning this, in case the documents aren't the optimal place for the info - I hate to state the obvious, but a complete WB description of the above for all NT/SMB (or just transact2) would be pretty big. Perhaps a KB article that we can reference from a WB? There I go again. Another understatement. :) Chris -)- -- Implementing CIFS - the Common Internet FileSystem ISBN: 013047116X Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- c...@ubiqx.mn.org OnLineBook -- http://ubiqx.org/cifs/-)- c...@ubiqx.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] CAR: userParameters attribute
Dear Dochelp, The userParameters attribute on a user in AD seems to be a bit of a puzzle. Could you add some docs on it at some stage? Not a really high priority, but we would eventually like to be able to offer admin tools that manage things like session activity timeouts, and it seems that we need to know how to parse and create userParameters to do that. An example userParameters attribute from w2k8r2 (in base64 form) is this: userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0 aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya 0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm Ft44Cw the above came from using the windows user admin tool to change the session activity timeout for a test user. Michael Ströder has also pointed out this page: http://daduke.org/linux/userparameters.html which documents a previous effort by the Linux thin client community to work out the format of userParameters. I'm guessing the strange encoding is used to try to keep the attribute as valid UTF8. If you can confirm that the attribute is always valid UTF8 that would be great (as otherwise we might corrupt it during replication with windows). As I mentioned, this is not a high priority, but it would be nice to know the format at some stage. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [REG:110011477385004] Intial Response: RE: userParameters attribute
Hi, Tridge, Thanks for your question. One of our team member will work on your request and get back to you when the investigation is done. Thanks! Hongwei Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - -Original Message- From: tri...@samba.org [mailto:tri...@samba.org] Sent: Thursday, January 14, 2010 2:55 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net; Michael Ströder Subject: CAR: userParameters attribute Dear Dochelp, The userParameters attribute on a user in AD seems to be a bit of a puzzle. Could you add some docs on it at some stage? Not a really high priority, but we would eventually like to be able to offer admin tools that manage things like session activity timeouts, and it seems that we need to know how to parse and create userParameters to do that. An example userParameters attribute from w2k8r2 (in base64 form) is this: userParameters:: Q3R4Q2ZnUHJlc2VudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgUAsaCAFDdHhDZmdQcmVzZW5045S15pSx5oiw44GiIAIBQ3R4V0ZQcm9maWxlUGF0aOOAsBgCAU N0eFdGSG9tZURpcuOAsCICAUN0eFdGSG9tZURpckRyaXZl44CwEggBQ3R4U2hhZG9344Sw44Cw44C w44CwLggBQ3R4TWF4RGlzY29ubmVjdGlvblRpbWXjgaXjjLnjkLDjgLAoCAFDdHhNYXhDb25uZWN0 aW9uVGltZeOAtOOct+aIseOAsBwIAUN0eE1heElkbGVUaW1l44Gj45yy46Sw44CwIAIBQ3R4V29ya 0RpcmVjdG9yeeOAsBgIAUN0eENmZ0ZsYWdzMeOAsOOBpuOYsuOAuCICAUN0eEluaXRpYWxQcm9ncm Ft44Cw the above came from using the windows user admin tool to change the session activity timeout for a test user. Michael Ströder has also pointed out this page: http://daduke.org/linux/userparameters.html which documents a previous effort by the Linux thin client community to work out the format of userParameters. I'm guessing the strange encoding is used to try to keep the attribute as valid UTF8. If you can confirm that the attribute is always valid UTF8 that would be great (as otherwise we might corrupt it during replication with windows). As I mentioned, this is not a high priority, but it would be nice to know the format at some stage. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] What elements of the DIT are required for AD to operate?
Hi Hongwei, I just want to give you a quick update on this request. The product team is helping us review the list of minimum initial DIT we compiled from the documentation in the MS-ADTS. I will let you know once it is complete. Thanks! I should also mention that while we'd like to get this answered, it is no longer holding us up. Previously we were able to use dcpromo only if the directory had been initially created on windows. If it was created by Samba then dcpromo would fail. That is what led to this request as we knew that something was wrong with our initialisation of the directory, but we didn't know what. Now we've got past that problem after we applied the schema fixes we mentioned in another CAR. We'd still like to see something saying what elements of the directory are needed by windows DCs and clients, especially if you can tell us what is needed for the different functional levels, but it is no longer holding up our core development, so the urgency is a bit lower than before. Related to this, we've been puzzling a bit as to whether we should create some of the groups that show up on some windows DCs, for example the TelnetClients group, and the IIS_IUSRS groups. We suspect we do need to create the ones that use fixed SIDs, and perhaps don't need to create the ones that use dynamically allocated SIDs, as we suspect the latter ones (like TelnetClients) is created when windows components are installed, even if the directory was created by Samba. It would be good to get this confirmed. Similarly, we suspect some of the foreign security principles might need to be pre-created when we create the directory. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
