Re: [cifs-protocol] [REG:210063056197932001] Need some clarification on the User-Change-Password access rights
Good morning Nadya – Bill Wesse here; Obaid is out of the office, and I will be your contact for this case. Could you send me a network capture of the CONSTRAINT_VIOLATION error you are receiving? Thanks in advance; this will help us in making sure we get things right! 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: Friday, July 16, 2010 9:48 AM To: nivan...@samba.org nivan...@samba.org Cc: cifs-proto...@samba.org cifs-proto...@samba.org; MSSolve Case Email casem...@microsoft.com Subject: [REG:210063056197932001] Need some clarification on the User-Change-Password access rights Hi Nadya: Thank you for clarification. I’ll get back to you as soon as I have an answer. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft From: didr...@gmail.com [mailto:didr...@gmail.com] On Behalf Of Nadezhda Ivanova Sent: Tuesday, July 06, 2010 10:58 AM To: Obaid Farooqi Cc: cifs-proto...@samba.org; MSSolve Case Email Subject: Re: [REG:210063056197932001] Need some clarification on the User-Change-Password access rights Hi Obaid, I am looking at: 5.1.3.3.4 Checking Control Access Right-Based Access and 2.5.4.1 Access Check Algorithm Pseudocode In the access check algorithms, every time an access check is failed, insufficient access is returned, I did not see an instance of constraint violation. In 5.1.3.3.4, it is mentioned that in this and this case we deny the requested access, which leads me to believe insufficient access is returned. If constraint violation is the correct response for particular case, I think we definitely need some disambiguation on a per Control Access Right basis... Regards, Nadya On Tue, Jul 6, 2010 at 6:44 PM, Obaid Farooqi oba...@microsoft.commailto:oba...@microsoft.com wrote: Hi Nadya: Please let me know according to which document you should receive INSUFFICIENT_ACCESS_RIGHTS. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft From: Obaid Farooqi Sent: Thursday, July 01, 2010 10:22 AM To: 'nivan...@samba.orgmailto:nivan...@samba.org' Cc: cifs-proto...@samba.orgmailto:cifs-proto...@samba.org; MSSolve Case Email Subject: RE:[REG:210063056197932001] Need some clarification on the User-Change-Password access rights Hi Nadya: My name is Obaid Farooqi and I’ll be helping you with this issue. I’ll be in touch as soon as I have anything concrete. Please feel free to contact me if you have a question/clarification. Regards, Obaid Farooqi Sr. Support Escalation Engineer | Microsoft From: didr...@gmail.commailto:didr...@gmail.com [mailto:didr...@gmail.commailto:didr...@gmail.com] On Behalf Of Nadezhda Ivanova Sent: Wednesday, June 30, 2010 6:31 AM To: Interoperability Documentation Help; cifs-proto...@samba.orgmailto:cifs-proto...@samba.org Subject: Need some clarification on the User-Change-Password access rights Hello, I am currently working on enforcing the User-Change-Password control access right on password change operations in Samba 4, and there are a few things that puzzle me, perhaps you could help. I am testing agains a Win2008 server, domain and forest functional levels are 2008. The user object class has the following ACE in the defaultSecurityDescriptor: (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD), OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS) I created a user and removed these two for the purposes of negative testing. However, when I performed a password change operation(delete and add of unicodePwd), I got CONSTRAINT_VIOLATION error rather than INSUFFICIENT_ACCESS_RIGHTS. I granted the user write property access, but the result was the same. Alternatively, a user to whom I explicitly denied WP access was able to change their password if they have User-Change-Password. So my question is: Is the write access to unicodePwd controlled only by User-Change-Password, and WP is disregarded in this case? Why is the error returned CONSTRAINT_VIOLATION? Also, given that by default we this control access right is granted to EVERYONE, this means that the actual line of defence is the changer knowing the original password. If they know the password, it does not matter which account changes the user's password, which makes sense. However, in this case, why bother with checking User-Change-Password at all? It appears that its purpose is to allow a user (or any account for that matter) to change the password even if they do not have WP access on themselves, am I correct? Best Regards, Nadya Microsoft is committed to protecting your privacy. Please read the Microsoft Privacy Statementhttp://go.microsoft.com/fwlink/?LinkId=81184 for more information. The above is an email for a support case from Microsoft Corp. REPLY ALL TO THIS MESSAGE
Re: [cifs-protocol] [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2
Hi Andrew, here is the current status of your request. We have submitted a request to our product team to complete a validated and combined schema for Windows 2000, 2003, 2003R2, 2008 and 2008R2, incorporating all TDI’s submitted against [MS-ADA1], [MS-ADA2], [MS-ADA3], [MS-ADSC] and [MS-ADTS]. Please expect this to take at least several weeks before we have any results. I will keep you posted. Also, please note that the text schemas in the SchemaTextFilesAndDisplaySpecifiers.zip I sent on Wed 6/30/2010 are the most recent we have provided, with the exception of the Windows 2008 files - 2k8\MS-AD_Schema_2K8_*.txt; 2k8\DisplaySpecifiers-Win2k8.txt is current with the other display specifier text files. In the meantime, if you aren’t already aware of the following blog entries, I would like to bring them to your attention, as they bear somewhat on your efforts. On the same topic, I have attached ‘DumpSchema.cmd.txt’, which will invoke ldifde.exe to dump a Windows 2xxx AD domain RootDSE and Configuration trees into .ldf files (it will ask if you want to change the domain/DC/user, which are preselected from environment variables). Understanding the minimum set of DIT elements required by the first DC using MS-ADTS http://blogs.msdn.com/b/openspecification/archive/2010/03/18/understanding-the-minimum-set-of-dit-elements-required-by-the-first-dc-using-ms-adts.aspx Using the Windows Server Protocols documentation set to better understand the Active Directory Schema http://blogs.msdn.com/b/openspecification/archive/2009/06/26/using-the-windows-server-protocols-documentation-set-to-better-understand-the-active-directory-schema.aspx 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.com Tel: +1(980) 776-8200 Cell: +1(704) 661-5438 Fax: +1(704) 665-9606 -Original Message- From: Bill Wesse Sent: Thursday, July 08, 2010 6:51 AM To: Bill Wesse bil...@microsoft.com Cc: MSSolve Case Email casem...@microsoft.com; cifs-proto...@samba.org cifs-proto...@samba.org Subject: [REG:110062452298172] Re: Text-file Schema for all of 2000-2008R2 On Thu, 2010-07-01 at 17:21 +, Bill Wesse wrote: A quick update: Confirmation on time/dates of the latest schema text files will be forthcoming after the July 6 meeting I mentioned below. Sorry I won't be able to confirm before that. Thanks again for your patience... No worries. I would rather wait until you have absolute confidence that these schema files match the schema in Windows than spend time debugging why they don't match. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. @echo off if defined _vect_ goto :%_vect_% setlocal set _this_=%~f0 set _esep_=== set _vect_=GetDefaultSettings call %_this_% set _vect_=EchoSettings call %_this_% echo. set _resp_= set /p _resp_=Enter 'y' to change these settings: if %_resp_% equ goto :Perform if /i %_resp_:~0,1% neq y goto :Perform set _vect_=GetDomainName call %_this_% set _vect_=CrackDomainName call %_this_% set _vect_=GetDCName call %_this_% set _vect_=GetUserName call %_this_% set _vect_=EchoSettings call %_this_% set _vect_=DumpOnePartition call %_this_% %_from_% Configuration call %_this_% %_from_% goto :Exit :DumpOnePartition echo. echo %_esep_% set _root_=%~1 if %~2 equ ( set _file_=RootDSE.ldf goto :DumpOnePartitionExecute ) shift set _file_=%~1.ldf :DumpOnePartitionNextSubtree if %~1 equ goto :DumpOnePartitionExecute set _root_=CN=%~1,%_root_% shift goto :DumpOnePartitionNextSubtree :DumpOnePartitionExecute echo Exporting: %USERDNSDOMAIN% echoTo: %_file_% echo Root: %_root_% echo. if exist %_file_% del /f %_file_%nul ldifde.exe %_sarg_%%_uarg_%-d %_root_% -f %_file_% set _errn_=%errorlevel% if %_errn_% neq 0 ( echo Error: %_errn_% echo Deleting: %_file_% del /f %_file_%nul ) goto :EOF :CrackDomainName set _vect_=CrackDnsDomainName set _from_= for /f tokens=1-26 delims=. %%a in (%_ddns_%) do call %_this_% %%a %%b %%c %%d %%e %%f %%g %%h %%i %%j %%k %%l %%m %%n %%o %%p %%q %%r %%s %%t %%u %%v %%w %%x %%y %%z set _vect_=CrackDomainName goto :EOF :CrackDnsDomainName if %~1 equ goto :EOF if %_from_% equ ( set _from_=DC=%~1 ) else ( set _from_=%_from_%,DC=%~1 ) shift goto :CrackDnsDomainName :GetDefaultSettings set _ddns_=%USERDNSDOMAIN% set _serv_=%LOGONSERVER:~2% set _user_= set _pass_= set _from_= set _vect_=CrackDomainName call %_this_% %_ddns_% goto :EOF :EchoSettings echo. echo %_esep_% echo Domain: %_ddns_% echo BaseDN: %_from_% if %_serv_% equ ( echo Server: DC of %_ddns_% ) else ( echo Server: %_serv_% ) if %_user_% neq ( echo User: %_user_% ) if %_pass_% neq ( echo Passwd: %_pass_% ) goto
Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP
Glad to have been of assistance! 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Monday, February 01, 2010 8:21 AM To: Bill Wesse; abart...@samba.org Cc: Obaid Farooqi; p...@tridgell.net; Sebastian Canevari; cifs-proto...@samba.org Subject: RE: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP Thanks Bill, Btw, we've implemented prefixMap over ldap dump handler and it works great. Many thanks for publishing the format. BR, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Monday, February 01, 2010 3:14 PM To: abart...@samba.org; Kamen Mazdrashki Cc: Sebastian Canevari; Obaid Farooqi; p...@tridgell.net; cifs- proto...@samba.org Subject: RE: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP Good morning again. Sebastian will be back in the office today; I have transferred case ownership back to him. 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: Bill Wesse Sent: Thursday, January 28, 2010 11:46 AM To: 'abart...@samba.org'; 'kamen.mazdras...@postpath.com' Cc: Sebastian Canevari; Obaid Farooqi; 'p...@tridgell.net'; 'cifs- proto...@samba.org' Subject: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP Good day Andrew Kamen. Please note that my colleague Sebastian (who took ownership of this case from Obaid) is out of the office for the next few days. In the interim, I will be your contact. Thanks in advance for your patience! Andrew - I sent a status update request for the TDI (which has been in suspense since one of your previous emails (shown at the end of this message). I will advise you as soon as I receive a response. Kamen - I have already performed some investigation concerning those 20 other prefixMap entries, and expect to follow up with your tomorrow morning. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Friday, January 15, 2010 3:09 AM To: Obaid Farooqi; abart...@samba.org Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP Hi Obaid, Could you please point out where those default 39 entries for prefixMap are described? I am looking at: http://msdn.microsoft.com/en- us/library/cc228445%28PROT.13%29.aspx and there are only 19 default prefixes listed here. Thanks, Kamen Mazdrashki kamen.mazdras...@postpath.com mailto:kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -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 Bartlett http://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
Re: [cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP
Good morning again. Sebastian will be back in the office today; I have transferred case ownership back to him. 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: Bill Wesse Sent: Thursday, January 28, 2010 11:46 AM To: 'abart...@samba.org'; 'kamen.mazdras...@postpath.com' Cc: Sebastian Canevari; Obaid Farooqi; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: Status: SRX09600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP Good day Andrew Kamen. Please note that my colleague Sebastian (who took ownership of this case from Obaid) is out of the office for the next few days. In the interim, I will be your contact. Thanks in advance for your patience! Andrew - I sent a status update request for the TDI (which has been in suspense since one of your previous emails (shown at the end of this message). I will advise you as soon as I receive a response. Kamen - I have already performed some investigation concerning those 20 other prefixMap entries, and expect to follow up with your tomorrow morning. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Friday, January 15, 2010 3:09 AM To: Obaid Farooqi; abart...@samba.org Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP Hi Obaid, Could you please point out where those default 39 entries for prefixMap are described? I am looking at: http://msdn.microsoft.com/en-us/library/cc228445%28PROT.13%29.aspx and there are only 19 default prefixes listed here. Thanks, Kamen Mazdrashki kamen.mazdras...@postpath.com mailto:kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -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] [REG:110012953632586] RE: Bug in MS-WINSRA section 2.2.10.1 Name Record
Thanks Stefan - forwarding this email to Edgar, who owns the case. 110012953632586 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: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Saturday, January 30, 2010 4:40 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Bill, there's one additional bug regarding the Name length. Name (variable): Name terminates with a 0x00 byte. It may include a NetBIOS scope identifier, as specified in [RFC1001]. The maximum length of the Name field is 255 bytes including the 0x00 byte. If no NetBIOS scope is included, then the length of the name is 17 including the 0x00 byte. When a windows server gets a name with length == 255 it removes the last character of the scope before storing it. Windows returns a name with length 254 when it returns the name again. See the attached capture (172.31.9.211 is Windows 2008 and 172.31.9.1 is a modified smbtorture). Frame 19 smbtorture = windows 2008 name length 255 Frame 25 windows 2008 = smbtorture name length 254 metze Good morning Stefan - I am including our below initial response, since I missed CC: doch...@microsoft.com on the first one. -Original Message- From: Bill Wesse Sent: Friday, January 29, 2010 9:59 AM To: 'me...@samba.org' Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect Good morning Stefan - thanks for your comments. I have created the below case to track the issue. One of my team members will contact you shortly! 110012953632586 [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect 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: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, January 29, 2010 9:25 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi, I found a bug in MS-WINSRA section 2.2.10.1 Name Record. It says: Padding (variable): If the Name field is not 4-byte aligned, this Padding field will be added to pad to 4-byte alignment. If the Name field itself is 4-byte aligned, then there is no Padding field. This field MUST be ignored upon receipt. This is wrong! The documentation would indicate this: pad_len = ((offset (4-1)) == 0 ? 0 : (4 - (offset (4-1 But Windows Servers (at least 2003 SP1 and 2008) use this: pad_len = 4 - (offset (4-1)); The difference is the case where the name field is already 4 byte aligned. In that case Windows adds 4 bytes instead of 0 bytes of aligment. See frame 75 in the attached capture (172.31.9.211 is a windows 2008 server and 172.31.9.1 a modified smbtorture). The name length is 20 and there're 4 extra bytes before the Reserved1 field. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Good morning Stefan - I am including our below initial response, since I missed CC: doch...@microsoft.com on the first one. -Original Message- From: Bill Wesse Sent: Friday, January 29, 2010 9:59 AM To: 'me...@samba.org' Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: [REG:110012953632586] [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect Good morning Stefan - thanks for your comments. I have created the below case to track the issue. One of my team members will contact you shortly! 110012953632586 [MS-WINSRA] 2.2.10.1 Name Record Padding field description incorrect 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: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, January 29, 2010 9:25 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi, I found a bug in MS-WINSRA section 2.2.10.1 Name Record. It says: Padding (variable): If the Name field is not 4-byte aligned, this Padding field will be added to pad to 4-byte alignment. If the Name field itself is 4-byte aligned, then there is no Padding field. This field MUST be ignored upon receipt. This is wrong! The documentation would indicate this: pad_len = ((offset (4-1)) == 0 ? 0 : (4 - (offset (4-1 But Windows Servers (at least 2003 SP1 and 2008) use this: pad_len = 4 - (offset (4-1)); The difference is the case where the name field is already 4 byte aligned. In that case Windows adds 4 bytes instead of 0 bytes of aligment. See frame 75 in the attached capture (172.31.9.211 is a windows 2008 server and 172.31.9.1 a modified smbtorture). The name length is 20 and there're 4 extra bytes before the Reserved1 field. metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count
Good morning Zachary - I located the CIFS/SMB presentation information; sorry for the delay. It has been a pleasure serving you in this matter! Redocumenting Historic CIFS http://www.snia.org/events/storage-developer2009/presentations/monday/ChrisHertel_Redocumenting_Historic_CIFS.pdf Christopher Hertel CTO, ubiqx Development, Inc Pages 15, 16, 22, 39 40 list 'technical definition' information. 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: Bill Wesse Sent: Thursday, December 17, 2009 12:30 PM To: 'Zachary Loafman' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: OPEN_ANDX undocumented flag with 19 word count response No problem! Some information on CIFS/SMB (both the technical and legal definitions, which differ) was presented at the Sept '09 SNIA Plugfest, and it may take me a bit to obtain the presentation materials - hopefully that won't take too long. I will keep you advised! 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: Zachary Loafman [mailto:zachary.loaf...@isilon.com] Sent: Thursday, December 17, 2009 12:27 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: OPEN_ANDX undocumented flag with 19 word count response Bill - Thanks! I apologize for not checking MS-SMB as well, woops. -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Thursday, December 17, 2009 9:25 AM To: Zachary Loafman Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: OPEN_ANDX undocumented flag with 19 word count response Good morning Zachary - thanks for your questions. We have created the following case to track our work on those: SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count I expect the lack of documentation in [MS-CIFS] concerning your questions is due to the relationship between CIFS and SMB, and because the flags and fields in question are SMB extensions to CIFS. I will dig deeper into this and will update you as soon as I can. Here is some initial information for you concerning where the flags and fields in question are documented: SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count The SMB_COM_OPEN_ANDX.Flags SMB_OPEN_EXTENDED_RESPONSE (0x0010) flag is documented here: 2.2.10 SMB_COM_OPEN_ANDX Client Request Extension http://msdn.microsoft.com/en-us/library/cc246255.aspx The WordCount value of 19 is documented here: 3.3.5.6 Receiving an SMB_COM_OPEN_ANDX Request (Obsolete) http://msdn.microsoft.com/en-us/library/cc246463.aspx The ServerField is documented here: 2.2.11 SMB_COM_OPEN_ANDX Server Response Extension http://msdn.microsoft.com/en-us/library/cc246256.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: Zachary Loafman [mailto:zachary.loaf...@isilon.com] Sent: Thursday, December 17, 2009 10:18 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: OPEN_ANDX undocumented flag with 19 word count response If the client adds a 0x10 flag in the Flags field of SMB_COM_OPEN_ANDX, a Windows server will send back an alternate 19 WordCount response. Neither the 0x10 flag nor the 19 WordCount response are documented in MS-CIFS. Wireshark can't handle the flag or response, but netmon seems to document it. The flag is documented as RESP_EXTENDED_OPEN_ANDX reply, and the reply seems to contain the MaxAccessRights (as the torture test expects, too). Both the flag and response need to be documented, though. Also, the MS-CIFS OPEN_ANDX documentation doesn't mention ServerFID, but both netmon and wireshark think that the first ULONG worth of the Reserved field is actually ServerFID, whatever that is. I've attached a short pcap demonstrating the extended response. You can reproduce this at will with the smbtorture RAW-OPEN test. -- Zach Loafman | Staff Engineer Isilon SystemsD +1-206-315-7570F +1-206-315-7485 www.isilon.comP +1-206-315-7500M +1-206-422-3461 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status: SRX091111600231 [MS-ADA3]: 2.115 Structure of prefixMap over LDAP
Good day Andrew Kamen. Please note that my colleague Sebastian (who took ownership of this case from Obaid) is out of the office for the next few days. In the interim, I will be your contact. Thanks in advance for your patience! Andrew - I sent a status update request for the TDI (which has been in suspense since one of your previous emails (shown at the end of this message). I will advise you as soon as I receive a response. Kamen - I have already performed some investigation concerning those 20 other prefixMap entries, and expect to follow up with your tomorrow morning. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Friday, January 15, 2010 3:09 AM To: Obaid Farooqi; abart...@samba.org Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP Hi Obaid, Could you please point out where those default 39 entries for prefixMap are described? I am looking at: http://msdn.microsoft.com/en-us/library/cc228445%28PROT.13%29.aspx and there are only 19 default prefixes listed here. Thanks, Kamen Mazdrashki kamen.mazdras...@postpath.com mailto:kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -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
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Good morning Matthieu. Thanks for your patience. Our documentation team has responded to 3 of the four cross-reference requests. Details are shown below, as well as an attached pdf ([MS-ADTS]_Changes.pdf) showing new text for that document. 1. A request was made for a link in '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes', pointing to '[MS-LSAD] section 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES'. We haven't added this link because the relationship between the trustedDomain!msDs-supportedEncryptionTypes attribute and TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES structure is already specified in '[MS-LSAD] section 3.1.1.5 Trusted Domain Object Data Model'. 2. A request was made for a link in '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes', pointing to '[MS-NRPC] section 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes)'. We haven't added this link, because we think this link would be inappropriate, since these two sections are about two different types of object. '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes' is about trustedDomain objects; however, the NETLOGON_DOMAIN_INFO structure in '[MS-NRPC] section 2.2.1.3.11 NETLOGON_DOMAIN_INFO' provides information on a domain joined computer object. Therefore, instead of adding a cross reference between trustedDomain!msDs-supportedEncryptionTypes and NETLOGON_DOMAIN_INFO, we have added text in the [MS-ADTS] sections noted below providing information on the msDs-supportedEncryptionTypes attribute of the computer object. [MS-ADTS] 7.4.1 State of a Machine Joined to a Domain [MS-ADTS] 7.4.2 State in an Active Directory Domain [MS-ADTS] 7.4.3 Relationship to Protocols 3. A request was made for links in '[MS-LSAD] section 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES', pointing to '[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes' and '[MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO' (SupportedEncTypes). We haven't added these links, because when describing the member SupportedEncTypes of struct NETLOGON_DOMAIN_INFO, '[MS-NRPC] section 2.2.1.3.11 NETLOGON_DOMAIN_INFO' links to section '[MS-LSAD] 2.2.7.18 TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES', which describes the structure represented in SupportedEncTypes. Additionally '[MS-LSAD] section 3.1.1.5 Trusted Domain Object Data Model' references '[MS-ADTS] section 7.1.6.7.3 msDs-supportedEncryptionTypes' to link the data retrieved from AD. Also, [MS-LSAD] does not need to reference [MS-NRPC] for the purposes of supported encryption types because MS-LSAD does not consume any encryption type definition in [MS-NRPC]. Additionally, [MS-LSAD] supportedEncryptionTypes usage is for trusts only, whereas [MS-NRPC] supportedEncryptionTypes usage is for both trusts and computers. 4. A request was made for links in '[MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO (SupportedEncTypes)', pointing to '[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes'. This request is currently pending review. 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
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] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx 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: Bill Wesse Sent: Monday, January 11, 2010 1:46 PM To: 'Matthieu Patou' Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: RE: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Good afternoon Matthieu - holidays are good! I've attached a pdf with some changes I am proposing to Sebastian concerning updates to the blog entry. Also, I have (hopefully adequate) answers to your first two questions (I will be working on the last ones about the doc cross-refs NETLOGON_DOMAIN_INFO, as I have some diligence to do on NETLOGON_DOMAIN_INFO). == Unanswered questions == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between ms-SupportedEncryptionTypes and SupportedEncTypes as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Also one last question: the very first time the SupportedEncTypes is returned as the DC as no information about the workstation what should be returned ? 0x00 of 0xFF or something else. == Answers... == Question 1 == First this page http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx; still state Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed, not all of them are aware of its existence hence, older versions (2003 and earlier) do not populate it at any time. even if you just said that this added by some version (vista/w2k8 and higher) will it be updated ? Also you are basically saying that having ADS_UF_USE_DES_KEY_ONLY don't make any difference because the content of msDS-SupportedEncryptionTypes will not present for everything up to XP/w2k3r2, then 1F for vista/w2k8 then 1C for w7/w2k8r2. == Response 1 == I have attached an update to the blog (also as a change proposal to Sebastian), which removes that 'attribute
Re: [cifs-protocol] Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage
Thanks Matthieu - I will create the new case for the below...(I'm just lazy about Wireshark/keytab, I guess). Could you advise me on how this impacts your implementation progess (this is important for the TDI priority)? Also, I agree NETLOGON_DOMAIN_INFO.SupportedEncTypes returned from (Windows 2008 R2) NetrLogonGetDomainInfo as 0x (a.k.a. (ULONG)-1) is not documented. I think this should indicate to the client that an update to SupportedEncTypes is needed. Also note that an incoming value of 0 also means a client is pre-Vista (Windows), and/or is ignorant of the msDS-SupportedEncryptionTypes attribute. That, of course, will be the gist of what will go into the TDI for the new case. == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Tuesday, January 12, 2010 2:08 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Sebastian Canevari Subject: Re: Status: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage Hi bill, It seems quite ok ! About question2 what we see is mostly 0xFF on server supporting this attribute (w2k8 and upper). Also as a tip for decoding encrypted with schannel you can use dev version of wireshark, we wrote some patch to decode this kind of traffic. Of course you will need keytab with passwords of workstation for decoding. This can be obtain with the net vampire of samba3 ! Matthieu. On 12/01/2010 18:38, Bill Wesse wrote: Hello again Matthieu - here are my follow ups to the unanswered questions. == Unanswered Question 1 == Sorry I don't really understand the change introduced, can you be just more clear and just say that there is a link between msDS-SupportedEncryptionTypes and SupportedEncTypes, as the first one is updated by the capable workstation upon reception of an incorrect value in the second one. Response: I have added your suggestion to the TDI against [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes (http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx). References: msDS-SupportedEncryptionTypes [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes http://msdn.microsoft.com/en-us/library/cc223853(PROT.13).aspx SupportedEncTypes [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx == Unanswered Question 2 == Also one last question: the very first time the SupportedEncTypes is returned, if the DC has no information about the workstation, what should be returned? 0x00 or 0xFF or something else. Response: As you have noted, NetrLogonGetDomainInfo behavior on this point is not documented (and a debug would be necessary for me to dig into actual behavior, since the calls are encrypted). Please confirm (or update) the accuracy of my rewording reflects you needs properly. Also, please advise me how this impacts your implementation - is that blocking work? I expect to create a new case and TDI for this, once you respond. References: [MS-NRPC] 3.5.5.3.9 NetrLogonGetDomainInfo (Opnum 29) http://msdn.microsoft.com/en-us/library/cc237247(PROT.13).aspx [MS-NRPC] 2.2.1.3.11 NETLOGON_DOMAIN_INFO http://msdn.microsoft.com/en-us/library/cc237052(PROT.13).aspx Regards, Bill Wesse
[cifs-protocol] Status: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
Good morning Tim. I filed a Technical Documentation Issue (TDI) concerning the [MS-SMB] 2.2 Message Syntax error returns. This is still under investigation by our document developers, and I will advise you as soon as some results are forthcoming. I included your comments and questions in the TDI: 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. In addition, WordCount and ByteCount might not be present in the response. Specifically, some commands override the SMB_FLAGS2_NT_STATUS Flags2 bit; for example, SMB_COM_TRANSACTION2 / TRANS2_SET_PATH_INFORMATION / SMB_SET_FILE_END_OF_FILE_INFO (an invalid level) clears SMB_FLAGS2_NT_STATUS on return, and sets the error to: DOSError.ErrorClass (0x0001, 1d) : SMB_ERR_CLASS_DOS DOSError.Error (0x007C, 124d) : SrvErrorCode(STATUS_OS2_INVALID_LEVEL) see attached file: trans2setpathinfo_against_win7_2.cap (frames 39 40) 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: Friday, December 11, 2009 10:19 AM To: 'Tim Prouty' Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: RE: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header Good morning Tim. There are indeed other cases where WordCount and ByteCount are not sent; I have located several dozen potential SMB response cases where this could occur. The Technical Document Issue (TDI) I filed yesterday includes this as an issue, along with when a DOSError is returned with the header.Flags2 SMB_FLAGS2_NT_STATUS bit clear in the response when it was set in the request - which is all about where this will be documented - and who will do the detailing. Whether or not WordCount and ByteCount are absent for all DOSError returns is not yet something I can yet provide an authoritative answer for. My thinking is that [MS-SMB] (Appendix A: Product Behavior), [MS-CIFS-Preview], and the Microsoft Open Specification Support Team Blog are all viable targets for the information in question. [MS-CIFS-Preview]: Common Internet File System (CIFS) http://msdn.microsoft.com/en-us/library/ee794904.aspx [MS-SMB]: Server Message Block (SMB) Protocol Specification http://msdn.microsoft.com/en-us/library/cc246231(PROT.13).aspx Microsoft Open Specification Support Team Blog http://blogs.msdn.com/OpenSpecification/ Today, I will be concentrating on the final steps I need to take before filing a TDI against the other case (SRX091124600335 : [MS-SMB] Trans2SetPathInfo() not enforcing share mode). 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: Thursday, December 10, 2009 2:39 PM To: Bill Wesse Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: Re: 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] Status: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
FYI - the TDI was filed on Dec 10... 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: Thursday, December 31, 2009 9:04 AM To: 'Tim Prouty' Cc: 'Jeremy Allison'; 'cifs-proto...@samba.org'; 'p...@tridgell.net' Subject: Status: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header Good morning Tim. I filed a Technical Documentation Issue (TDI) concerning the [MS-SMB] 2.2 Message Syntax error returns. This is still under investigation by our document developers, and I will advise you as soon as some results are forthcoming. I included your comments and questions in the TDI: 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. In addition, WordCount and ByteCount might not be present in the response. Specifically, some commands override the SMB_FLAGS2_NT_STATUS Flags2 bit; for example, SMB_COM_TRANSACTION2 / TRANS2_SET_PATH_INFORMATION / SMB_SET_FILE_END_OF_FILE_INFO (an invalid level) clears SMB_FLAGS2_NT_STATUS on return, and sets the error to: DOSError.ErrorClass (0x0001, 1d) : SMB_ERR_CLASS_DOS DOSError.Error (0x007C, 124d) : SrvErrorCode(STATUS_OS2_INVALID_LEVEL) see attached file: trans2setpathinfo_against_win7_2.cap (frames 39 40) 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: Friday, December 11, 2009 10:19 AM To: 'Tim Prouty' Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: RE: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header Good morning Tim. There are indeed other cases where WordCount and ByteCount are not sent; I have located several dozen potential SMB response cases where this could occur. The Technical Document Issue (TDI) I filed yesterday includes this as an issue, along with when a DOSError is returned with the header.Flags2 SMB_FLAGS2_NT_STATUS bit clear in the response when it was set in the request - which is all about where this will be documented - and who will do the detailing. Whether or not WordCount and ByteCount are absent for all DOSError returns is not yet something I can yet provide an authoritative answer for. My thinking is that [MS-SMB] (Appendix A: Product Behavior), [MS-CIFS-Preview], and the Microsoft Open Specification Support Team Blog are all viable targets for the information in question. [MS-CIFS-Preview]: Common Internet File System (CIFS) http://msdn.microsoft.com/en-us/library/ee794904.aspx [MS-SMB]: Server Message Block (SMB) Protocol Specification http://msdn.microsoft.com/en-us/library/cc246231(PROT.13).aspx Microsoft Open Specification Support Team Blog http://blogs.msdn.com/OpenSpecification/ Today, I will be concentrating on the final steps I need to take before filing a TDI against the other case (SRX091124600335 : [MS-SMB] Trans2SetPathInfo() not enforcing share mode). 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: Thursday, December 10, 2009 2:39 PM To: Bill Wesse Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: Re: 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
Re: [cifs-protocol] of SupportedEncTypes and msDS-SupportedEncryptionTypes
I agree with you - the blog entry is wrong, and your statement is correct - the network capture frame details below illustrate this (a Windows 2008 client joining a 2008 domain). I am cc'ing Sebastian, since he owns the blog entry. In fact that's not only w2k/xp/w2k3 it's the whole range. My assumption is that this phrase :Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed is false and that when the computer object is created it is created without this attribute and then systems newer or equal to vista/windows 2k8 are modifying this attribute to set it to the exact value that they support. Frame: Number = 634, Captured Frame Length = 254, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-04-7B-09],SourceAddress:[00-15-5D-04-7B-14] + Ipv4: Src = 192.168.0.11, Dest = 192.168.0.10, Next Protocol = TCP, Packet ID = 102, Total IP Length = 240 + Tcp: Flags=...AP..., SrcPort=49166, DstPort=LDAP(389), PayloadLen=200, Seq=4221789663 - 4221789863, Ack=3194344992, Win=512 (scale factor 0x8) = 131072 - Ldap: Modify Request, MessageID: 5, Object: CN=2008R2VMDC2,CN=Computers,DC=2008R2DOMAIN,DC=COM + SASLBuffer: - Parser: Modify Request, MessageID: 5 + ParserHeader: + MessageID: 5 + OperationHeader: Modify Request, 6(0x6) - ModifyRequest: Object: CN=2008R2VMDC2,CN=Computers,DC=2008R2DOMAIN,DC=COM + Object: CN=2008R2VMDC2,CN=Computers,DC=2008R2DOMAIN,DC=COM - LoopSeq: + OuterSequenceHeader: - Modification: Replace + InnerSequence: + Operation: Replace, 2(0x2) - Modification: msDS-SupportedEncryptionTypes=( 28 ) + PartialAttributeHeader: 0x1 + Type: msDS-SupportedEncryptionTypes + AttributeValuesHeader: - Attribute: 28 + AsnOctetStringHeader: OctetStream: 28 - Controls: + ControlsHeader: + ControlHeader: + ControlType: 1.2.840.113556.1.4.1413 (LDAP_SERVER_PERMISSIVE_MODIFY_OID) + ControlValueHeader: 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Monday, December 21, 2009 11:22 AM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: of SupportedEncTypes and msDS-SupportedEncryptionTypes Hello bill Good morning Matthieu - We have created the below case to track our work against your questions: SRX091220600031 [MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage I will begin my investigation this morning, and will advise you of my progress by close of business tomorrow (Tuesday Dec 22 GMT-5) at the latest. I confirm the msDS-SupportedEncryptionTypes attribute is not set when a Windows 2000 or Windows XP client joins a Windows 2008 domain. I will next check the msDS-SupportedEncryptionTypes attribute with a Windows 2003 server on a 2008 domain, and expect to verify the behavior within several hours (once my virtual machine has completed installation). In fact that's not only w2k/xp/w2k3 it's the whole range. My assumption is that this phrase :Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed is false and that when the computer object is created it is created without this attribute and then systems newer or equal to vista/windows 2k8 are modifying this attribute to set it to the exact value that they support. Matthieu. 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: Matthieu Patou [mailto:mat+informatique.sa...@matws.net] Sent: Sunday, December 20, 2009 7:01 AM To: cifs-proto...@samba.org; Interoperability Documentation Help; p...@tridgell.net Subject: of SupportedEncTypes and msDS-SupportedEncryptionTypes Hello, Back in august and september we discuss in case SRX090808600017 about supportedEncTypes and I was quite happy with your answer. I'm coming back on this subject for two details: * this blog entry (of msdn) http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx says : Although this attribute is present in all the computer objects of the domain regardless of the version of the OS the physical machines have installed, not all of them are aware of its existence hence, older versions (2003 and earlier) do not populate it at any time. It means that when I join a w2k8 domain with a XP workstation that the DC will create a computer object for this XP workstation and set the msDS
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] [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] OPEN_ANDX undocumented flag with 19 word count response
Good morning Zachary - thanks for your questions. We have created the following case to track our work on those: SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count I expect the lack of documentation in [MS-CIFS] concerning your questions is due to the relationship between CIFS and SMB, and because the flags and fields in question are SMB extensions to CIFS. I will dig deeper into this and will update you as soon as I can. Here is some initial information for you concerning where the flags and fields in question are documented: SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count The SMB_COM_OPEN_ANDX.Flags SMB_OPEN_EXTENDED_RESPONSE (0x0010) flag is documented here: 2.2.10 SMB_COM_OPEN_ANDX Client Request Extension http://msdn.microsoft.com/en-us/library/cc246255.aspx The WordCount value of 19 is documented here: 3.3.5.6 Receiving an SMB_COM_OPEN_ANDX Request (Obsolete) http://msdn.microsoft.com/en-us/library/cc246463.aspx The ServerField is documented here: 2.2.11 SMB_COM_OPEN_ANDX Server Response Extension http://msdn.microsoft.com/en-us/library/cc246256.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: Zachary Loafman [mailto:zachary.loaf...@isilon.com] Sent: Thursday, December 17, 2009 10:18 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: OPEN_ANDX undocumented flag with 19 word count response If the client adds a 0x10 flag in the Flags field of SMB_COM_OPEN_ANDX, a Windows server will send back an alternate 19 WordCount response. Neither the 0x10 flag nor the 19 WordCount response are documented in MS-CIFS. Wireshark can't handle the flag or response, but netmon seems to document it. The flag is documented as RESP_EXTENDED_OPEN_ANDX reply, and the reply seems to contain the MaxAccessRights (as the torture test expects, too). Both the flag and response need to be documented, though. Also, the MS-CIFS OPEN_ANDX documentation doesn't mention ServerFID, but both netmon and wireshark think that the first ULONG worth of the Reserved field is actually ServerFID, whatever that is. I've attached a short pcap demonstrating the extended response. You can reproduce this at will with the smbtorture RAW-OPEN test. -- Zach Loafman | Staff Engineer Isilon SystemsD +1-206-315-7570F +1-206-315-7485 www.isilon.comP +1-206-315-7500M +1-206-422-3461 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] OPEN_ANDX undocumented flag with 19 word count response
No problem! Some information on CIFS/SMB (both the technical and legal definitions, which differ) was presented at the Sept '09 SNIA Plugfest, and it may take me a bit to obtain the presentation materials - hopefully that won't take too long. I will keep you advised! 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: Zachary Loafman [mailto:zachary.loaf...@isilon.com] Sent: Thursday, December 17, 2009 12:27 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: OPEN_ANDX undocumented flag with 19 word count response Bill - Thanks! I apologize for not checking MS-SMB as well, woops. -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Thursday, December 17, 2009 9:25 AM To: Zachary Loafman Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: OPEN_ANDX undocumented flag with 19 word count response Good morning Zachary - thanks for your questions. We have created the following case to track our work on those: SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count I expect the lack of documentation in [MS-CIFS] concerning your questions is due to the relationship between CIFS and SMB, and because the flags and fields in question are SMB extensions to CIFS. I will dig deeper into this and will update you as soon as I can. Here is some initial information for you concerning where the flags and fields in question are documented: SRX091217600064 [MS-CIFS] OPEN_ANDX undocumented flag with 19 word count The SMB_COM_OPEN_ANDX.Flags SMB_OPEN_EXTENDED_RESPONSE (0x0010) flag is documented here: 2.2.10 SMB_COM_OPEN_ANDX Client Request Extension http://msdn.microsoft.com/en-us/library/cc246255.aspx The WordCount value of 19 is documented here: 3.3.5.6 Receiving an SMB_COM_OPEN_ANDX Request (Obsolete) http://msdn.microsoft.com/en-us/library/cc246463.aspx The ServerField is documented here: 2.2.11 SMB_COM_OPEN_ANDX Server Response Extension http://msdn.microsoft.com/en-us/library/cc246256.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: Zachary Loafman [mailto:zachary.loaf...@isilon.com] Sent: Thursday, December 17, 2009 10:18 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: OPEN_ANDX undocumented flag with 19 word count response If the client adds a 0x10 flag in the Flags field of SMB_COM_OPEN_ANDX, a Windows server will send back an alternate 19 WordCount response. Neither the 0x10 flag nor the 19 WordCount response are documented in MS-CIFS. Wireshark can't handle the flag or response, but netmon seems to document it. The flag is documented as RESP_EXTENDED_OPEN_ANDX reply, and the reply seems to contain the MaxAccessRights (as the torture test expects, too). Both the flag and response need to be documented, though. Also, the MS-CIFS OPEN_ANDX documentation doesn't mention ServerFID, but both netmon and wireshark think that the first ULONG worth of the Reserved field is actually ServerFID, whatever that is. I've attached a short pcap demonstrating the extended response. You can reproduce this at will with the smbtorture RAW-OPEN test. -- Zach Loafman | Staff Engineer Isilon SystemsD +1-206-315-7570F +1-206-315-7485 www.isilon.comP +1-206-315-7500M +1-206-422-3461 ___ 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
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: Response, TID: 0x0800, PID: 0x77C9, UID: 0x0800, MID: 0x0008 + Flags: 136 (0x88) + Flags2: 34819 (0x8803) PIDHigh: 0 (0x0) SecuritySignature: 0x0 Unused: 0 (0x0) TreeID: 2048 (0x800) ProcessID: 30665 (0x77C9) UserID: 2048 (0x800) MultiplexID: 8 (0x8) 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 08, 2009 12:55 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 your diligence on this Bill and the answers you have provided. I have some responses inline below. On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote: Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? Response: #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + FileEndOfFileInformation is functionally equivalent to a remote call to NtSetInformationFile. NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the file system driver in question; this does not involve the usual I/O Manager ShareMode checks. I share the same sentiment as Zach on this behavior, but it is definitely useful to know how windows handles this. Are there plans for this to be documented anywhere or does it receive documentation exemption since this is passthrough-speceific? = = = = = = = = == Question: If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Response: This should be the case for all supported SMB_INFO_PASSTHROUGH levels, as they run through the same essential logic. However, I have additional testing to perform before I can completely confirm this. I am interested to know the results of your testing. I believe there are some tests in RAW-OPLOCKS that use the rename passthrough level to test oplocks, but implicitly rely on share modes not being enforced
Re: [cifs-protocol] [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: Response, TID: 0x0800, PID: 0x77C9, UID: 0x0800, MID: 0x0008 + Flags: 136 (0x88) + Flags2: 34819 (0x8803) PIDHigh: 0 (0x0) SecuritySignature: 0x0 Unused: 0 (0x0) TreeID: 2048 (0x800) ProcessID: 30665 (0x77C9) UserID: 2048 (0x800) MultiplexID: 8 (0x8) 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 08, 2009 12:55 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 your diligence on this Bill and the answers you have provided. I have some responses inline below. On Dec 8, 2009, at 6:07 AM, Bill Wesse wrote: Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? Response: #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + FileEndOfFileInformation
Re: [cifs-protocol] [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
Good morning Andrew. I have included your original question and my response below. Since I have not heard from you in quite a while, I will archive the case on Thursday; we can, of course, reopen it if you require that. Your original question from October 01: I refer here to the access control that would normally be imposed by the nTSecurityDescriptor and enforced over LDAP. It is my understanding (discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the actual workstation account), but I don't recall that being in the doc. (This isn't a security hole, because you can only update your own record, but it's important to note for those doing an ACL implementation). Response: The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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, November 23, 2009 6:39 AM To: 'Andrew Bartlett' Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Thanks for the update Andrew. I will hang in there, at your convenience. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Sunday, November 22, 2009 8:23 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) On Fri, 2009-11-20 at 18:02 +, Bill Wesse wrote: Good morning Andrew - I am resending this email from November 4. I did get the message, but was surprised by the contents and I've been unable to find the time to verify it. -Original Message- From: Bill Wesse Sent: Wednesday, November 04, 2009 12:22 PM To: 'Andrew Bartlett' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter Wallnöfer' Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - I am resending this email from October 29. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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: Thursday, October 29, 2009 9:36 AM To: 'Andrew Bartlett' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter Wallnöfer' Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - I am resending this email from October 20. Please let me know if this answers your question satisfactorily; if so, I will consider your question
Re: [cifs-protocol] New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
Good morning Tim. There are indeed other cases where WordCount and ByteCount are not sent; I have located several dozen potential SMB response cases where this could occur. The Technical Document Issue (TDI) I filed yesterday includes this as an issue, along with when a DOSError is returned with the header.Flags2 SMB_FLAGS2_NT_STATUS bit clear in the response when it was set in the request - which is all about where this will be documented - and who will do the detailing. Whether or not WordCount and ByteCount are absent for all DOSError returns is not yet something I can yet provide an authoritative answer for. My thinking is that [MS-SMB] (Appendix A: Product Behavior), [MS-CIFS-Preview], and the Microsoft Open Specification Support Team Blog are all viable targets for the information in question. [MS-CIFS-Preview]: Common Internet File System (CIFS) http://msdn.microsoft.com/en-us/library/ee794904.aspx [MS-SMB]: Server Message Block (SMB) Protocol Specification http://msdn.microsoft.com/en-us/library/cc246231(PROT.13).aspx Microsoft Open Specification Support Team Blog http://blogs.msdn.com/OpenSpecification/ Today, I will be concentrating on the final steps I need to take before filing a TDI against the other case (SRX091124600335 : [MS-SMB] Trans2SetPathInfo() not enforcing share mode). 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: Thursday, December 10, 2009 2:39 PM To: Bill Wesse Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: Re: 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
[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
[cifs-protocol] New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header
Hello Tim - I have created case SRX091209600095 to track this issue. My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will be testing against Windows 7, Windows Vista, and Windows XP (and Windows 2000 if necessary) before proceeding with any product bug filings. Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz From trans2setpathinfo_against_win7_2.cap in the attached zip (using Network Monitor 3.4): Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7] + Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol = TCP, Packet ID = 42077, Total IP Length = 230 + Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445), PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566 + SMBOverTCP: Length = 174 - Smb: C; Transact2, Set Path Info, Set File EOF Info, Path = \testsfileinfo\test_sfileinfo_end_of_file.dat Protocol: SMB Command: Transact2 50(0x32) + NTStatus: 0x0, Facility = FACILITY_SYSTEM, Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS + SMBHeader: Command, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID: 0x0009 - CTransaction2: WordCount: 15 (0xF) TotalParameterCount: 98 (0x62) TotalDataCount: 8 (0x8) MaxParameterCount: 2 (0x2) MaxDataCount: 0 (0x0) MaxSetupCount: 0 (0x0) Reserved: 0 (0x0) + Flags: Do NOT disconnect TID Timeout: 0 sec(s) Reserved2: 0 (0x0) ParameterCount: 98 (0x62) ParameterOffset: 68 (0x44) DataCount: 8 (0x8) DataOffset: 166 (0xA6) SetupCount: 1 (0x1) Reserved3: 0 (0x0) SubCommand: Set Path Info, 6(0x0006) ByteCount: 109 (0x6D) Pad1: Binary Large Object (3 Bytes) - SetPathInfoParameterBlock: InformationLevel: Set File EOF Info padding: 0 (0x0) + PathName: \testsfileinfo\test_sfileinfo_end_of_file.dat + EndOfFile: 200 Frame: Number = 40, Captured Frame Length = 102, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-3F-D2-D7],SourceAddress:[00-0C-29-84-0A-41] + Ipv4: Src = 10.54.159.10, Dest = 10.54.159.14, Next Protocol = TCP, Packet ID = 14043, Total IP Length = 88 + Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=58261, PayloadLen=36, Seq=108947765 - 108947801, Ack=2212563008, Win=260 + 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: Response, TID: 0x0800, PID: 0x5935, UID: 0x0800, MID: 0x0009 + Flags: 136 (0x88) + Flags2: 34819 (0x8803) PIDHigh: 0 (0x0) SecuritySignature: 0x0 Unused: 0 (0x0) TreeID: 2048 (0x800) ProcessID: 22837 (0x5935) UserID: 2048 (0x800) MultiplexID: 9 (0x9) 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 Captures.zip.bin Description: Captures.zip.bin ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] 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(0xC000F000L | SRV_STATUS_FACILITY_CODE) 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 09, 2009 12:24 PM To: Bill Wesse Cc: Jeremy Allison; cifs-proto...@samba.org; p...@tridgell.net Subject: Re: New case: SRX091209600095 Trans2SetPathInfo() returns truncated SMB header Thank you Bill. I'm looking forward to hearing the results of your investigation. -Tim On Dec 9, 2009, at 9:13 AM, Bill Wesse wrote: Hello Tim - I have created case SRX091209600095 to track this issue. My current test setup is Ubuntu 9.10 against Windows 2008 R2. I will be testing against Windows 7, Windows Vista, and Windows XP (and Windows 2000 if necessary) before proceeding with any product bug filings. Samba4 from: http://samba.org/~tprouty/samba.2009.12.08.tar.gz From trans2setpathinfo_against_win7_2.cap in the attached zip (using Network Monitor 3.4): Frame: Number = 39, Captured Frame Length = 244, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress: [00-0C-29-84-0A-41],SourceAddress:[00-0C-29-3F-D2-D7] + Ipv4: Src = 10.54.159.14, Dest = 10.54.159.10, Next Protocol = TCP, Packet ID = 42077, Total IP Length = 230 + Tcp: Flags=...AP..., SrcPort=58261, DstPort=Microsoft-DS(445), PayloadLen=178, Seq=2212562830 - 2212563008, Ack=108947765, Win=566 + SMBOverTCP: Length = 174 - Smb: C; Transact2, Set Path Info
Re: [cifs-protocol] What elements of the DIT are required for AD to operate? (SRX091208600025)
Good morning Andrew - thanks for your question - I have created the below case for us to track our efforts regarding that. One of my colleagues will take ownership and contact you shortly. SRX091208600025 : [MS-ADTS] required DIT elements for Active Directory forest 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, December 08, 2009 12:16 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: What elements of the DIT are required for AD to operate? G'day, In the last few months, we have had great success with joining a Window 2008 R2 server into a Samba4 hosted domain. It was a great achievement, and the speed of development we achieved over this difficult area is a testament to the support we received at the plugfest. However, that success was only possible when we have first joined Samba4 to an already operational Active Directory domain, and obtained the full database over DRS replication. Samba aims for and requires a high standard of interoperability - a standard of 'either Samba or Windows must be able provision/initialise the domain, without clients or other domain controllers seeing the difference'. However, during the development last week we also found out (by painful experience and in discussion with your developers) that Windows performs very few checks on the incoming replicated data, and is not tolerant of deviations from the expected form. So, to achieve this interoperability, we need to know precisely what things a windows domain controller needs across the directory replication channel, for it to become and operate correctly as a domain controller. Put another way: what are the required DIT elements for a server to provision to be the initiator of an Active Directory forest? We do already have many of these elements implemented - things like the Display Specifiers and Schema we were very glad to obtain earlier - but it seem there is much more required. Much of this is in the documentation set - particularly MS-ADTS, but scattered in a way that makes for a great reference, but a poor source for implementation (because it is so easy to miss one). My hope is that like the schema and display specifiers, that this information (effectively the minimum initial DIT) can also be made available to us in a similar, machine-readable fashion, for each supported functional level. Thanks, Andrew Bartlett -- Andrew Bartlett http://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
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Good morning Tim - here is a summary of my progress to-date concerning your questions. == Question: The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? Response: #3 is correct behavior. Sending an SMB_COM_TRANSACTION2 request for SET_PATH_INFORMATION with SMB_INFO_PASSTHROUGH + FileEndOfFileInformation is functionally equivalent to a remote call to NtSetInformationFile. NtSetInformationFile sends an IRP_MJ_SET_INFORMATION request to the file system driver in question; this does not involve the usual I/O Manager ShareMode checks. == Question: If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Response: This should be the case for all supported SMB_INFO_PASSTHROUGH levels, as they run through the same essential logic. However, I have additional testing to perform before I can completely confirm this. == Question: 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? Response: The WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce with my clients (who succeeded against the call). I have attached a zip file with your trace (trans2setpathinfo_against_win7_2.pcap), and my equivalent trace (test_trans2setpathinfo_Win7.pcap). Mine does not have that second Set EOF call. Do I need a newer build of smbtorture (my current one from you is samba.2009.12.01.tar.gz)? 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, December 04, 2009 12:45 PM To: 'Tim Prouty' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Thanks for the update - my Win7 client is also Ultimate, with no updates. On another note, I just finished an initial debug on srv.sys; I have considerable analysis to do on the results, specifically tracking down the handles (just to make sure - even though there are no handle failures in either standard or SMB_INFO_PASSTHROUGH FileEndOfFileInformation information level for TRANS2_SET_PATH_INFORMATION). There are additional functional checks on the information level, when less than SMB_INFO_PASSTHROUGH, which I still need to run down in the documentation. I doubt I will be able to finish my work today, and do expect to be able to provide some reasonable information early next week. Of course, this is all about what is supposed to be allowed when a client requests a 'native Windows NT operating system information level' ([MS-SMB] Appendix A note
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Thanks for the update - my Win7 client is also Ultimate, with no updates. On another note, I just finished an initial debug on srv.sys; I have considerable analysis to do on the results, specifically tracking down the handles (just to make sure - even though there are no handle failures in either standard or SMB_INFO_PASSTHROUGH FileEndOfFileInformation information level for TRANS2_SET_PATH_INFORMATION). There are additional functional checks on the information level, when less than SMB_INFO_PASSTHROUGH, which I still need to run down in the documentation. I doubt I will be able to finish my work today, and do expect to be able to provide some reasonable information early next week. Of course, this is all about what is supposed to be allowed when a client requests a 'native Windows NT operating system information level' ([MS-SMB] Appendix A note 158: http://msdn.microsoft.com/en-us/library/cc246806(PROT.13).aspx). I have thus far not been able to find any specific commentary on this in the WDK documentation (but then, I am not a driver expert). 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 -Original Message- From: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Friday, December 04, 2009 12:20 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Dec 3, 2009, at 10:04 AM, Bill Wesse wrote: I have retested without SmbSecuritySignatures - results were the same. I will hold off on the WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) for the time being, and work on the sharing issue (I expect to be soaking in code for the next day or so). My win7 is a fresh ultimate install with no updates. I'm going to run windows update to see if I can reproduce it. I'll let you know what I find out. -Tim ___ 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
I have retested without SmbSecuritySignatures - results were the same. I will hold off on the WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) for the time being, and work on the sharing issue (I expect to be soaking in code for the next day or so). Thanks for all your help with samba4/smbtorture (I am still having problems with gz on my Ubuntu client, so I unpacked it on my Windows client cloned the tree to Ubuntu). No problems at all with the build. 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: Thursday, December 03, 2009 12:32 PM To: 'Tim Prouty' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org' Subject: RE: [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Good morning Tim. I have successfully reproduced the share problem with Trans2SetPathInfo() FileEndOfFileInformation, using smbtorture (RAW-SFILEINFO-END-OF-FILE ) against both Windows 2008 R2 and Windows 7. This, of course, will allow me to dig deeper into the problem. Interestingly, WordCount/ByteCount truncation against the Dos INVALID_LEVEL error problem (trans2setpathinfo_against_win7_2.pcap) you saw did not reproduce with my clients (who succeeded against the ); the only significant difference I see in the traces you sent and my test traces is that my Win7/R2 targets were using SmbSecuritySignatures (your Win7 client did not). I have attached my network captures (in both Wireshark tcp dump Netmon 3.x format). I will retry with security signatures disabled and get back to you with the results. 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)
Hello Tridge - just checking in to see how things are going.
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)
Hello Tridge. Here is what I have (pending the proposed changes for [MS-ADTS]:
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
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: Thursday, November 12, 2009 9:44 AM
To: 'tri...@samba.org'
Cc: 'cifs-proto...@samba.org'; 'h...@highlandsun.com'
Subject: Re: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN
size in AD)
Good morning Tridge! Since Hongwei is out of the office, I have created case
SRX091112600056 to track our work against your question about rDN size /
deleted object rDN.
I expect to be able to begin work on this tomorrow, and will keep you updated!
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
Re: [cifs-protocol] Status: CAR: DS_FLAG Option bits (SRX091002600036 [MS-ADTS] 7.3.3.2 DS_FLAG option bits)
Hello Tridge - just checking in to see how things are going. 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 13, 2009 1:14 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) Hello again - glad to see you're back. Resending the below, FYI... 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. 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
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. 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
Re: [cifs-protocol] [Pfif] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
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] 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: 'Nadezhda Ivanova' Cc: cifs-proto...@samba.org Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169) Glad to help. I will look into the security descriptor handling. Have you seen anything different at lower functional levels (like only the specified sd parts being applied)? 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: Friday, November 20, 2009 1:21 PM 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, Thank you for your answer! The problem is, 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? Best 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, November 20, 2009 7:22:08 PM GMT+0200 Europe;Athens Subject: RE: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169) Just following up to clarify where we are on this, since I missed a beat yesterday
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Good morning Tim. Bill Wesse from the Documentation Support team here. I will be your contact for this issue. We have created the following case to track our investigation: SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode I will begin work this morning, and will update you with status before the end of the day. 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, November 24, 2009 6:07 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS-CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx). SMB_INFO_PASSTHROUGH levels request a native Windows NT operating system information level (as you already have noted) of the TRANS2_SET_* TRANS2_QUERY_* calls, and can be thought of as rough equivalents to ZwSetInformationFile and ZwQueryInformationFile: 1. Where the 'FILE_INFORMATION_CLASS FileInformationClass' parameter is equal to: (InformationLevel - SMB_INFO_PASSTHROUGH) : See MSDN WDF_FILE_INFORMATION_CLASS at http://msdn.microsoft.com/en-us/library/dd568296.aspx 2. The InformationLevels are restricted as noted in: [MS-SMB] 6 Appendix A: Product Behavior 158, 239, 240 and 242 at http://msdn.microsoft.com/en-us/library/cc246806.aspx [MS-FSCC] 5 Appendix A: Product Behavior note 47 specifies Windows uses the NtQueryInformationFile ... NtSetInformationFile ... The definition of the function used to process any file information request, including its content and the function signature, is implementation-dependent and is not part of the protocol specification. 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, November 25, 2009 8:30 AM To: 'Tim Prouty' Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: RE: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Good morning Tim. Bill Wesse from the Documentation Support team here. I will be your contact for this issue. We have created the following case to track our investigation: SRX091124600335 [MS-SMB] Trans2SetPathInfo() not enforcing share mode I will begin work this morning, and will update you with status before the end of the day. 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, November 24, 2009 6:07 PM To: Interoperability Documentation Help; cifs-proto...@samba.org; p...@tridgell.net Subject: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi, Based on the ZwSetInformationFile() docs (http://msdn.microsoft.com/en-us/library/ms804363.aspx) and from my testing of smb1 against a win7 share, in order to set FileEndOfFileInformation it is necessary that the file is first opened with FILE_WRITE_DATA in the access_mask. It then follows that a Trans2SetPathInfo for FileEndOfFileInformation should implicitly open the file with FILE_WRITE_DATA before either truncating or extending the file. The specific case I'm interested in is the following: 1. Client1 does a CreateFileAndX() on a non-existant file with a share mode of 0 and holds the file open. 2. Client 2 does a Trans2SetPathInfo() with the level set to FileEndOfFileInformation (0x104) as documented in the SNIA CIFS spec. As expected NT_STATUS_SHARING_VIOLATION is returned here. 3. Client 2 does a Trans2SetPathInfo() with the undocumented pass-through level that also allows setting the FileEndOfFileInformation (1020 / 0x3FC). The client specifies that it wants to extend the file size to 100. Interestingly, win7 and winXP will return NT_STATUS_SUCCESS and successfully extend the length of the file. This operation seems to be circumventing the share mode enforcement. Is #3 actually correct behavior that other servers should implement? If so, can the cases where share modes are not enforced be enumerated in the documentation? I have attached a pcap of a client executing these exact steps against a win7 server. Packet 27/28: Step 1 Packet 29/30: Step 2 Packet 33-36: Step 3 (and verifies that the file was indeed extended) Packet 37/38: Show that share modes should still be enforced. Thanks! -Tim
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Jeremy, I agree with you concerning Windows behavior needing to be documented; but I felt it necessary to mention the possibilities concerning further elaboration - since I am not the one to make that decision (nor do I wish to second guess those who do). My next step is to finish tracking down file handle visibility within the server, and how that applies to pass-through versus no pass-through: as you noted, there are certainly differences, the main one concerning why pass-through doesn't honor the share mode. My first take on this is to assume pass-through obtains the existing handle (making it safe to set the size); but I have not yet confirmed this (or proven it wrong - in which case I would be intensely bothered by the behavior, which would have the implication of corrupting the state of file state under the original handle). Either way, I do intend to file a TDI on the topic, once I finish the code study; I also intend to set up test code to exercise the information levels against the SMB calls. 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: Jeremy Allison [mailto:j...@samba.org] Sent: Wednesday, November 25, 2009 1:46 PM To: Bill Wesse Cc: Tim Prouty; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes On Wed, Nov 25, 2009 at 05:14:26PM +, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. That won't wash I'm afraid. If it's visible on the wire, and it changes the visible behaviour of the file server, then it needs to get documented. Jeremy. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes
Question: Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception? Response: I was paying more attention to the PID (0x26CD) - and didn't drill down closer to the sessions (both of which use the same security principal). Thanks for pointing that out; I will take it into account during my ongoing study (this implies a straight share mode bypass). Question: If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Response: That is certainly one of my goals - as I noted in my recent response to Jeremy, I intend to set up test code to exercise the information levels against the SMB calls. As I also mentioned, I will submit a TDI against this - before starting on any test code. Also, the best reference for the full roster of info levels is at: MSDN WDF_FILE_INFORMATION_CLASS http://msdn.microsoft.com/en-us/library/dd568296.aspx this being a subset: [MS-FSCC] 2.4 File Information Classes http://msdn.microsoft.com/en-us/library/cc232064.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: Tim Prouty [mailto:tim.pro...@isilon.com] Sent: Wednesday, November 25, 2009 1:21 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: Re: SMB1 Trans2SetPathInfo() FileEndOfFileInformation is not enforcing share modes Hi Bill, Thank you for the quick answer! I have a few comments/questions below. On Nov 25, 2009, at 9:14 AM, Bill Wesse wrote: Hello Tim. I think the difference in the response between the standard versus pass-through level lies in how the file handle is obtained during the call (given that TRANS2_SET_PATH_INFORMATION passes the path, and not the handle). The logical conclusion from the trace is that pass-through gets the existing handle, and the non pass-through value simply fails, because a new handle cannot be opened due to the lack of sharing. Which existing handle would the pass-through be using? The handle opened in packet #28 is a separate tcp connection and a separte session from the Trans2SetPathInfo in packet #33. I'm not aware of any situation where the server is expected to share file handles across multiple sessions. Is this an exception? I will continue my investigation into the details on the differences between the base pass-through handling, with respect to the file path / handle source. Pass-through is basically implementation dependent, as noted in [MS-FSCC] (reference below), so there is a possibility this may not be further elaborated on in the documents. If a client can send a particular info level and windows implements it, then we have a compatibility problem if we choose not to support it. What I would really like to know is if other SMB implementations need to circumvent share-mode checks for this pass through level (and maybe others?). Of course, TRANS2_SET_FILE_INFORMATION should succeed (without a pass-through value), since that requires the file handle (per [MS- CIFS] 2.2.6.9 TRANS2_SET_FILE_INFORMATION (0x0008) at http://msdn.microsoft.com/en-us/library/ee442064.aspx) . I agree. A Trans2SetFileInfo on the fid opened in packet #28 from the same session would have succeeded. -Tim ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
Good morning Andrew - I am resending this email from November 4. 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, November 04, 2009 12:22 PM To: 'Andrew Bartlett' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter Wallnöfer' Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - I am resending this email from October 29. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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: Thursday, October 29, 2009 9:36 AM To: 'Andrew Bartlett' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter Wallnöfer' Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - I am resending this email from October 20. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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 20, 2009 10:57 AM To: 'Andrew Bartlett' Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - here is the response from our document team. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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
Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
Hi Nadya - I will be your contact for this one. Here is the case number: SRX091119600169: [MS-ADTS] 7.1.3.2 LDAP_SERVER_SD_FLAGS_OID I will begin my investigation today! 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: Thursday, November 19, 2009 12:34 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org Subject: Need some help with LDAP_SERVER_SD_FLAGS_OID control Hello, I have been working on the implementation of LDAP_SERVER_SD_FLAGS_OID in Samba, and I have a question. Is this control relevant for an LDAP add request? I have been testing against Win2008. Adding this control to the request does not seem to have any effect. When I set it to Critical, I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in http://msdn.microsoft.com/en-us/library/aa367025%28VS.85%29.aspx At the same tine, in MS-ADTS, section 7.1.3.2 SD Flags Control, it says: When performing an LDAP operation (add, modify or search), the client may supply an SD flags control LDAP_SERVER_SD_FLAGS_OID with the operation. So, if the control is valid for an LDAP add, what should be the behavior? Best Regards, Nadezhda Ivanova ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169)
Nadya - I don't think the LDAP_SERVER_SD_FLAGS_OID control should have any effect during an add operation, since the flags for the control indicate which security descriptor parts to retrieve during a search, which should explain why LDAP_UNAVAILABLE_CRIT_EXTENSION is not being returned (assuming the add succeeded). I have filed a TDI to obtain authoritative information concerning this, and will update you with results as they develop. Could you advise me concerning how much this impacts progress on your implementation? References: [MS-ADTS] 3.1.1.3.4.1.11 LDAP_SERVER_SD_FLAGS_OID http://msdn.microsoft.com/en-us/library/cc223323(PROT.13).aspx The LDAP_SERVER_SD_FLAGS_OID control is used with an LDAP Search request to control the portion of a Windows Security Descriptor to retrieve. LDAP_SERVER_SD_FLAGS_OID Control Code http://msdn.microsoft.com/en-us/library/aa366987(VS.85).aspx The security information flags indicate which security descriptor parts to retrieve during a search. 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: Thursday, November 19, 2009 2:07 PM To: 'Nadezhda Ivanova' Cc: cifs-proto...@samba.org Subject: RE: Need some help with LDAP_SERVER_SD_FLAGS_OID control (SRX091119600169) Hi Nadya - I will be your contact for this one. Here is the case number: SRX091119600169: [MS-ADTS] 7.1.3.2 LDAP_SERVER_SD_FLAGS_OID I will begin my investigation today! 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: Thursday, November 19, 2009 12:34 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org Subject: Need some help with LDAP_SERVER_SD_FLAGS_OID control Hello, I have been working on the implementation of LDAP_SERVER_SD_FLAGS_OID in Samba, and I have a question. Is this control relevant for an LDAP add request? I have been testing against Win2008. Adding this control to the request does not seem to have any effect. When I set it to Critical, I do not get LDAP_UNAVAILABLE_CRIT_EXTENSION, as described in http://msdn.microsoft.com/en-us/library/aa367025%28VS.85%29.aspx At the same tine, in MS-ADTS, section 7.1.3.2 SD Flags Control, it says: When performing an LDAP operation (add, modify or search), the client may supply an SD flags control LDAP_SERVER_SD_FLAGS_OID with the operation. So, if the control is valid for an LDAP add, what should be the behavior? Best Regards, Nadezhda Ivanova ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013)
Hello Nadya - here are the results of my investigation. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. If you wish, I will keep the case open until the TDI has been resolved. The 'Sacl, Dacl, OwnerSid, GroupSid' data instance order you are seeing in the Windows self relative SECURITY_DESCRIPTOR is due to the Win API function 'MakeSelfRelativeSD' implementation, which emits them in that order. 'MakeAbsoluteSD' is order agnostic. This is why both [MS-DTYP] and MSDN define the SECURITY_DESCRIPTOR structure as opaque (references below). Given this, I expect that any SECURITY_DESCRIPTOR API functions should not make any assumptions concerning the appearance order of the target fields. Hence, I assert that both absolute and self-relative SECURITY_DESCRIPTOR pointer target fields should be assumed to be in no particular order. I have filed a TDI proposing clarification of this point in [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR. References: [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR http://msdn.microsoft.com/en-us/library/cc230366.aspx The self-relative form of the security descriptor is required if one wants to transmit the SECURITY_DESCRIPTOR structure as an opaque data structure for transmission in communication protocols over a wire, or for storage on secondary media; the absolute form cannot be transmitted because it contains pointers to objects that are generally not accessible to the recipient. SECURITY_DESCRIPTOR Structure http://msdn.microsoft.com/en-us/library/aa379561(VS.85).aspx Because the internal format of a security descriptor can vary, we recommend that applications not modify the SECURITY_DESCRIPTOR structure directly. For creating and manipulating a security descriptor, use the functions listed in See Also. See Also: GetSecurityDescriptorControl GetSecurityDescriptorDacl GetSecurityDescriptorGroup GetSecurityDescriptorLength GetSecurityDescriptorOwner GetSecurityDescriptorRMControl GetSecurityDescriptorSacl InitializeSecurityDescriptor IsValidSecurityDescriptor SetSecurityDescriptorDacl SetSecurityDescriptorGroup SetSecurityDescriptorOwner SetSecurityDescriptorRMControl SetSecurityDescriptorSacl 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, November 18, 2009 7:57 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Good morning Nadya! I will begin work on this for you this morning. I have created the below case: SRX091118600013 [MS-DTYP] 2.4.6 self relative form of SECURITY_DESCRIPTOR 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: Wednesday, November 18, 2009 6:26 AM To: Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: Question about self relative form of SECURITY_DESCRIPTOR Hello, In MS-DTYP, section 2.4.6 (the table on page 55), the self relative format of a security descriptor is described as follows: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl OwnerSid GroupSid Sacl Dacl However, what we receive from the wire from a Win2003 or Win2008 is in fact in the form: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl Sacl Dacl OwnerSid GroupSid Although it does not prevent parsing the security descriptor, on a binary level the encoding between Windows and Samba is different, because Samba's is as documented. Is this the desired behavior or something that will be fixed? Best Regards, Nadezhda Ivanova ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013)
As always, you are very welcome. Glad to have been of assistance! 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: Wednesday, November 18, 2009 11:50 AM To: Bill Wesse Cc: cifs-proto...@samba.org Subject: Re: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Hi Bill, Thank you, this answers my question. I supposed that the order is indeed irrelevant as long as the offsets are correct, just wanted to double-check because of the explicit ordering in MS-DTYP. 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: Wednesday, November 18, 2009 6:46:18 PM GMT+0200 Europe;Athens Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Hello Nadya - here are the results of my investigation. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. If you wish, I will keep the case open until the TDI has been resolved. The 'Sacl, Dacl, OwnerSid, GroupSid' data instance order you are seeing in the Windows self relative SECURITY_DESCRIPTOR is due to the Win API function 'MakeSelfRelativeSD' implementation, which emits them in that order. 'MakeAbsoluteSD' is order agnostic. This is why both [MS-DTYP] and MSDN define the SECURITY_DESCRIPTOR structure as opaque (references below). Given this, I expect that any SECURITY_DESCRIPTOR API functions should not make any assumptions concerning the appearance order of the target fields. Hence, I assert that both absolute and self-relative SECURITY_DESCRIPTOR pointer target fields should be assumed to be in no particular order. I have filed a TDI proposing clarification of this point in [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR. References: [MS-DTYP] 2.4.6 SECURITY_DESCRIPTOR http://msdn.microsoft.com/en-us/library/cc230366.aspx The self-relative form of the security descriptor is required if one wants to transmit the SECURITY_DESCRIPTOR structure as an opaque data structure for transmission in communication protocols over a wire, or for storage on secondary media; the absolute form cannot be transmitted because it contains pointers to objects that are generally not accessible to the recipient. SECURITY_DESCRIPTOR Structure http://msdn.microsoft.com/en-us/library/aa379561(VS.85).aspx Because the internal format of a security descriptor can vary, we recommend that applications not modify the SECURITY_DESCRIPTOR structure directly. For creating and manipulating a security descriptor, use the functions listed in See Also. See Also: GetSecurityDescriptorControl GetSecurityDescriptorDacl GetSecurityDescriptorGroup GetSecurityDescriptorLength GetSecurityDescriptorOwner GetSecurityDescriptorRMControl GetSecurityDescriptorSacl InitializeSecurityDescriptor IsValidSecurityDescriptor SetSecurityDescriptorDacl SetSecurityDescriptorGroup SetSecurityDescriptorOwner SetSecurityDescriptorRMControl SetSecurityDescriptorSacl 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, November 18, 2009 7:57 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: RE: Question about self relative form of SECURITY_DESCRIPTOR (SRX091118600013) Good morning Nadya! I will begin work on this for you this morning. I have created the below case: SRX091118600013 [MS-DTYP] 2.4.6 self relative form of SECURITY_DESCRIPTOR 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: Wednesday, November 18, 2009 6:26 AM To: Interoperability Documentation Help Cc: cifs-protoc...@samba.org Subject: Question about self relative form of SECURITY_DESCRIPTOR Hello, In MS-DTYP, section 2.4.6 (the table on page 55), the self relative format of a security descriptor is described as follows: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl OwnerSid GroupSid Sacl Dacl However, what we receive from the wire from a Win2003 or Win2008 is in fact in the form: Revision Sbz1 Control OffsetOwner OffsetGroup OffsetSacl OffsetDacl Sacl Dacl
[cifs-protocol] Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)
Hello Tridge. Here is what I have (pending the proposed changes for [MS-ADTS]:
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
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: Thursday, November 12, 2009 9:44 AM
To: 'tri...@samba.org'
Cc: 'cifs-proto...@samba.org'; 'h...@highlandsun.com'
Subject: Re: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN
size in AD)
Good morning Tridge! Since Hongwei is out of the office, I have created case
SRX091112600056 to track our work against your question about rDN size /
deleted object rDN.
I expect to be able to begin work on this tomorrow, and will keep you updated!
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: Hongwei Sun
Sent: Thursday, November 12, 2009 12:56 PM
To: 'tri...@samba.org'
Cc: cifs-proto...@samba.org; h...@highlandsun.com; Edgar Olougouna; Sebastian
Canevari
Subject: RE: limits on rDN size in AD ?
Tridge,
The RDN of Deleted Objects container is a little different from the normal
RDN. The following information in MS-ADTS 3.1.1.5.5 describes the composition
of RDN for objects in Deleted Object container:
The RDN
Re: [cifs-protocol] limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on rDN size in AD)
Good morning Tridge! Since Hongwei is out of the office, I have created case SRX091112600056 to track our work against your question about rDN size / deleted object rDN. I expect to be able to begin work on this tomorrow, and will keep you updated! 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: Hongwei Sun Sent: Thursday, November 12, 2009 12:56 PM To: 'tri...@samba.org' Cc: cifs-proto...@samba.org; h...@highlandsun.com; Edgar Olougouna; Sebastian Canevari Subject: RE: limits on rDN size in AD ? Tridge, The RDN of Deleted Objects container is a little different from the normal RDN. The following information in MS-ADTS 3.1.1.5.5 describes the composition of RDN for objects in Deleted Object container: 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. It looks like to me that for the Delete Objects container, the size constraint should be dependent on the combination of the each sub component. Since I am out of office, I will ask one of my team member to investigate and confirm the behavior. Thanks ! -Original Message- 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] [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
Good morning Andrew - I am resending this email from October 29. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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: Thursday, October 29, 2009 9:36 AM To: 'Andrew Bartlett' Cc: 'p...@tridgell.net'; 'cifs-proto...@samba.org'; 'Matthias Dieter Wallnöfer' Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - I am resending this email from October 20. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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 20, 2009 10:57 AM To: 'Andrew Bartlett' Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - here is the response from our document team. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, October 01, 2009 6:52 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Mon, 2009-09-28 at 13:22 +, Bill Wesse wrote: Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (as Hongwei noted). This applies
Re: [cifs-protocol] [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015)
Good morning Andrew - I am resending this email from October 20. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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 20, 2009 10:57 AM To: 'Andrew Bartlett' Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [MS-ADTS] servicePrincipalName nTSecurityDescriptor (SRX090727600015) Good morning Andrew - here is the response from our document team. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. The actual updates for Validate Rights (by the DSA) is done as SYSTEM; however, the access check is performed with the client authorization context. According to section 5.1.3 in [MS-ADTS] (Authorization), a domain controller performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. As you know, access control information associated with an object is contained in the security descriptor of the object. Therefore, all Validated Writes ([MS-ADTS] 3.1.1.5.3.1.1) are subject to the access control imposed by the security descriptor. In this particular case, the access check is done against the security context of the workstation account, which is granted the RIGHT_DS_WRITE_PROPERTY_EXTENDED access on both dnsHostName and servicePrincipalName attributes of the computer object. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, October 01, 2009 6:52 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Mon, 2009-09-28 at 13:22 +, Bill Wesse wrote: Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (as Hongwei noted). This applies to Windows 2003/2003 R2, and was fixed in Windows 2008 and beyond. This is currently a bug against Windows 2003, but no hotfix has yet been produced. I will be glad to alert you to when this occurs. Here is the response Hongwei provided Thursday, September 10, 2009 8:40 AM: We confirmed that Windows server 2008 and later systems addressed the problem by implementing validation of the DNSHostName and SPN in NetrLogonGetDomainInfo to enforce the same constraints as specified in section 3.1.1.5.3.1.1.2(dNSHostName) and 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. I'm sorry, I must not have been clear in my point: Did we determine earlier that these updates occur regardless of the access control on the object (confirmed with AD Dev team, but I don't think it's in the docs). I refer here to the access control that would normally be imposed by the nTSecurityDescriptor and enforced over LDAP. It is my understanding (discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the actual workstation account), but I don't recall that being in the doc. (This isn't a security hole, because you can only update your own record, but it's important to note for those doing an ACL implementation). 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
Re: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
You are very welcome. Could you advise me concerning how much this is affecting your implementation development, so that I can set the TDI priority appropriately? I have cross-compared the Windows 2003 and Windows 2008 R2 implementations of the MakeAttid() and OidFromAttid() functions; there appear to be no functional changes. I suspect there is some corner-case not fully described in the attid composition in MakeAttid (lastValue ≥ 16384). procedure MakeAttid(var t: PrefixTable, o: OID): ATTRTYP ... /*compose the attid*/ lowerWord := lastValue mod 16384 if lastValue ≥ 16384 then /*mark it so that it is known to not be the whole lastValue*/ lowerWord := lowerWord + 32768 endif 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 4:16 AM To: Bill Wesse; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi Bill, Thanks for your support. I am looking forward to hearing from you soon. Regards, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Wednesday, October 21, 2009 7:37 PM To: Kamen Mazdrashki; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Good afternoon Kamen. This is Bill Wesse from the Protocol Support team. I will be your contact for the case noted below, where you asked about prefixMap implementation differences for Windows 2003 and Windows 2008 R2. SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation I will keep you updated with the results of my investigation as details develop. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Tuesday, October 20, 2009 9:36 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi, I need a clarification about what are the differences between prefixMap implementation for Win2K3 and Win2K8(R2). Attached you may find: 1. LDIF file to provision AD Schema with some test Attributes - OIDs of those attributes are crafted so that different scenarios could be tested. 2. Log files gathered during execution of Samba's RPC-DSSYNC test against Win2K3 and Win2K8. I am sending the log files as Word documents so it is easy for me to highlight interesting parts from the log files. -- prefixMap received is highlighted with 'gray'; newly added entries are highlighted with 'yellow' -- newly added object attributes received are also highlighted with 'yellow' 3. For testing I was using: -- Win2k3 R2 - Domain functional level = Win 2000 installation -- Win2K8 R2 - Domain functional lever = Win 2008 R2 -- Samba 4 - latest build. Test run is RPC-DSSYNC. Command line for testing: $ bin/smbtorture -Uadministrator%333 -- configfile=/usr/local/samba/etc/drsuapi.conf ncacn_ip_tcp:Win_machine_ip[print,seal] RPC-DSSYNC -d1 As you may see, for Win2K3 everything works correctly as described in MS-DRSR, section 5.12.2. I.e. attribute with attid=0x1B860001 matches prefixMap entry with id=0x1b86 and thus Attribute OID is correctly decoded as being '1.2.250.1' In Win2k8 log file however, for attid=0x85C6D3B9 matching prefixMap entry should be id=0x4823 and it is not quite obvious how 0x85C6D3B9 is matched to 0x4823? Please, clarify what is the algorithm used under Win2k8 for MakeAttid() and OidFromAttid() functions? Many thanks in advance. Regards, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Hello again, Kamen. Could you forward the LDIF file to me? I want to make sure I haven't missed anything (thanks). Also, I have again reviewed the MakeAttid() and OidFromAttid() pseudo code in [MS-DRSR] 5.16.4 (ATTRTYP-to-OID Conversion) - they do appear to be accurate representations of our implementations; my earlier comment about a 'corner-case' was an error, I got mixed up between string binary OIDs. There is certainly something else going on here, and I will continue working on it. 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: Thursday, October 22, 2009 8:51 AM To: 'Kamen Mazdrashki' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation You are very welcome. Could you advise me concerning how much this is affecting your implementation development, so that I can set the TDI priority appropriately? I have cross-compared the Windows 2003 and Windows 2008 R2 implementations of the MakeAttid() and OidFromAttid() functions; there appear to be no functional changes. I suspect there is some corner-case not fully described in the attid composition in MakeAttid (lastValue ≥ 16384). procedure MakeAttid(var t: PrefixTable, o: OID): ATTRTYP ... /*compose the attid*/ lowerWord := lastValue mod 16384 if lastValue ≥ 16384 then /*mark it so that it is known to not be the whole lastValue*/ lowerWord := lowerWord + 32768 endif 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 4:16 AM To: Bill Wesse; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi Bill, Thanks for your support. I am looking forward to hearing from you soon. Regards, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Wednesday, October 21, 2009 7:37 PM To: Kamen Mazdrashki; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Good afternoon Kamen. This is Bill Wesse from the Protocol Support team. I will be your contact for the case noted below, where you asked about prefixMap implementation differences for Windows 2003 and Windows 2008 R2. SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation I will keep you updated with the results of my investigation as details develop. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Tuesday, October 20, 2009 9:36 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi, I need a clarification about what are the differences between prefixMap implementation for Win2K3 and Win2K8(R2). Attached you may find: 1. LDIF file to provision AD Schema with some test Attributes - OIDs of those attributes are crafted so that different scenarios could be tested. 2. Log files gathered during execution of Samba's RPC-DSSYNC test against Win2K3 and Win2K8. I am sending the log files as Word documents so it is easy for me to highlight interesting parts from the log files. -- prefixMap received is highlighted with 'gray'; newly added entries are highlighted with 'yellow' -- newly added object attributes received are also highlighted with 'yellow' 3. For testing I was using: -- Win2k3 R2 - Domain functional level = Win 2000 installation -- Win2K8 R2 - Domain functional lever = Win 2008 R2 -- Samba 4 - latest build. Test run is RPC-DSSYNC. Command line for testing: $ bin/smbtorture -Uadministrator%333 -- configfile=/usr/local/samba/etc/drsuapi.conf ncacn_ip_tcp:Win_machine_ip[print,seal] RPC-DSSYNC -d1 As you may see, for Win2K3 everything works correctly as described in MS-DRSR, section 5.12.2. I.e. attribute with attid=0x1B860001 matches prefixMap entry with id=0x1b86 and thus Attribute OID is correctly
Re: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Thanks for the advisory - I will follow up with you on the attid - I will be expanding my code study on this. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 10:56 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi Bill, Currently this issue stops me from implementing MakeAttid() and OidFromAttid() to work transparently in all cases - from Win2k3 to Win2k8. Also I can't make a reasonable unit test for those functions. Nevertheless, it is not a 'show stopper' for me at this stage, as current implementation (following MS-DRSR) work well for Win2k3 and Win2k8 (without modifying schema). Attached you may find: - LDIF file; - 2 logs - from Win2k3 (Functional Level = Win 2000) and Win2k8-R2 (Functional Level = Win 2008 R2); - smb conf file used for testing, in case you want to try it by yourself I am currently on making an resume for Win2k8 result I got from windows server. It seems not to be a corner case to me. It seems more like a special case for Win2k8 - ATTIDs for all newly created attributes are with 31-th bit set. Regards, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Thursday, October 22, 2009 5:50 PM To: Kamen Mazdrashki Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hello again, Kamen. Could you forward the LDIF file to me? I want to make sure I haven't missed anything (thanks). Also, I have again reviewed the MakeAttid() and OidFromAttid() pseudo code in [MS-DRSR] 5.16.4 (ATTRTYP-to-OID Conversion) - they do appear to be accurate representations of our implementations; my earlier comment about a 'corner-case' was an error, I got mixed up between string binary OIDs. There is certainly something else going on here, and I will continue working on it. 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: Thursday, October 22, 2009 8:51 AM To: 'Kamen Mazdrashki' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation You are very welcome. Could you advise me concerning how much this is affecting your implementation development, so that I can set the TDI priority appropriately? I have cross-compared the Windows 2003 and Windows 2008 R2 implementations of the MakeAttid() and OidFromAttid() functions; there appear to be no functional changes. I suspect there is some corner-case not fully described in the attid composition in MakeAttid (lastValue ≥ 16384). procedure MakeAttid(var t: PrefixTable, o: OID): ATTRTYP ... /*compose the attid*/ lowerWord := lastValue mod 16384 if lastValue ≥ 16384 then /*mark it so that it is known to not be the whole lastValue*/ lowerWord := lowerWord + 32768 endif 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, October 22, 2009 4:16 AM To: Bill Wesse; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi Bill, Thanks for your support. I am looking forward to hearing from you soon. Regards, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ -Original Message- From: Bill Wesse [mailto:bil...@microsoft.com] Sent: Wednesday, October 21, 2009 7:37 PM To: Kamen Mazdrashki; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Good afternoon Kamen. This is Bill Wesse from the Protocol Support team. I will be your contact for the case noted below, where you asked about prefixMap implementation differences
Re: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation
Good afternoon Kamen. This is Bill Wesse from the Protocol Support team. I will be your contact for the case noted below, where you asked about prefixMap implementation differences for Windows 2003 and Windows 2008 R2. SRX091020600112 [MS-DRSR] section 5.12.2 - prefixMap implementation I will keep you updated with the results of my investigation as details develop. 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: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Tuesday, October 20, 2009 9:36 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: [cifs-protocol] Question about [MS-DRSR] section 5.12.2 - prefixMap implementation Hi, I need a clarification about what are the differences between prefixMap implementation for Win2K3 and Win2K8(R2). Attached you may find: 1. LDIF file to provision AD Schema with some test Attributes - OIDs of those attributes are crafted so that different scenarios could be tested. 2. Log files gathered during execution of Samba's RPC-DSSYNC test against Win2K3 and Win2K8. I am sending the log files as Word documents so it is easy for me to highlight interesting parts from the log files. -- prefixMap received is highlighted with 'gray'; newly added entries are highlighted with 'yellow' -- newly added object attributes received are also highlighted with 'yellow' 3. For testing I was using: -- Win2k3 R2 - Domain functional level = Win 2000 installation -- Win2K8 R2 - Domain functional lever = Win 2008 R2 -- Samba 4 - latest build. Test run is RPC-DSSYNC. Command line for testing: $ bin/smbtorture -Uadministrator%333 --configfile=/usr/local/samba/etc/drsuapi.conf ncacn_ip_tcp:Win_machine_ip[print,seal] RPC-DSSYNC -d1 As you may see, for Win2K3 everything works correctly as described in MS-DRSR, section 5.12.2. I.e. attribute with attid=0x1B860001 matches prefixMap entry with id=0x1b86 and thus Attribute OID is correctly decoded as being '1.2.250.1' In Win2k8 log file however, for attid=0x85C6D3B9 matching prefixMap entry should be id=0x4823 and it is not quite obvious how 0x85C6D3B9 is matched to 0x4823? Please, clarify what is the algorithm used under Win2k8 for MakeAttid() and OidFromAttid() functions? Many thanks in advance. Regards, Kamen Mazdrashki kamen.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git - CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
Thanks for the clarification Andrew; sorry I didn't. I have created a new case for this, and will begin work shortly: SRX091001600015 [MS-ADTS] servicePrincipalName nTSecurityDescriptor constraints I will look into object security / impersonation, including all of the below (with first effort on servicePrincipalName, of course), and get back to you as soon as I can. My first thought is that the Windows DS Agent simply impersonates 'SYSTEM' - but as you noted, undocumented (which probably classifies this as a behavior note). [MS-ADTS] 3.1.1.5.3.1.1 Validated Writes 3.1.1.5.3.1.1.1 Member 3.1.1.5.3.1.1.2 dNSHostName 3.1.1.5.3.1.1.3 msDS-AdditionalDnsHostName 3.1.1.5.3.1.1.4 servicePrincipalName 3.1.1.5.3.1.1.5 msDS-Behavior-Version 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, October 01, 2009 6:52 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Mon, 2009-09-28 at 13:22 +, Bill Wesse wrote: Good morning Andrew - yes, NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (as Hongwei noted). This applies to Windows 2003/2003 R2, and was fixed in Windows 2008 and beyond. This is currently a bug against Windows 2003, but no hotfix has yet been produced. I will be glad to alert you to when this occurs. Here is the response Hongwei provided Thursday, September 10, 2009 8:40 AM: We confirmed that Windows server 2008 and later systems addressed the problem by implementing validation of the DNSHostName and SPN in NetrLogonGetDomainInfo to enforce the same constraints as specified in section 3.1.1.5.3.1.1.2(dNSHostName) and 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. I'm sorry, I must not have been clear in my point: Did we determine earlier that these updates occur regardless of the access control on the object (confirmed with AD Dev team, but I don't think it's in the docs). I refer here to the access control that would normally be imposed by the nTSecurityDescriptor and enforced over LDAP. It is my understanding (discussion with Nathan Muggli) that these are done as 'SYSTEM' (not the actual workstation account), but I don't recall that being in the doc. (This isn't a security hole, because you can only update your own record, but it's important to note for those doing an ACL implementation). 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
Re: [cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Good afternoon Nadya! I have provided below a set of links for information that pertains to Active Directory permissions. There does not appear to be a specific guide for what the default permissions on a given Active Directory object, other than the Schema documents available at the following link. Please let me know if you have any specific questions concerning these that I have not already answered. If you have no further questions, I will consider your question resolved. Using the Windows Server Protocols documentation set to better understand the Active Directory Schema http://blogs.msdn.com/openspecification/archive/2009/06/26/using-the-windows-server-protocols-documentation-set-to-better-understand-the-active-directory-schema.aspx For example, there are 232 defaultSecurityDescriptor (SDDL formatted) attributes in MS-AD_Schema_2K8_R2_Consolidated.txt (which is in the Schemas.zip attachment to the blog entry). Understanding security descriptor defaulting rules for Active Directory objects http://blogs.msdn.com/openspecification/archive/2009/08/28/understanding-security-descriptor-defaulting-rules-for-active-directory-objects.aspx Active Directory Technical Specification Control Access Rights Concordance http://blogs.msdn.com/openspecification/archive/2009/08/19/active-directory-technical-specification-control-access-rights-concordance.aspx How to Use Dsacls.exe in Windows Server 2003 and Windows 2000 http://support.microsoft.com/default.aspx/kb/281146 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: Tuesday, September 22, 2009 12:48 PM To: 'nadezhda.ivan...@postpath.com' Cc: 'cifs-proto...@samba.org' Subject: SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions Good day Nadya (please let me know if I am using your name correctly)! I have created case SRX090922600157, in order to track our work concerning your questions (shown below). Hopefully, we have not missed anything you are enquiring after. 1. Why are the domain admins also provided full permissions if not needed for replication? 2. Is this for the administrative purposes only? 7.1.1.1.2 Config NC Root 7.1.1.1.3 Schema NC Root 7.1.1.1.4 Domain NC Root In order for D2 to replicate the NC, D2 must be granted the following rights on the NC root... 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SRX090922600157 : [MS-ADTS] 7.1.1.1 Naming Contexts Domain Admins Permissions
Good day Nadya (please let me know if I am using your name correctly)! I have created case SRX090922600157, in order to track our work concerning your questions (shown below). Hopefully, we have not missed anything you are enquiring after. 1. Why are the domain admins also provided full permissions if not needed for replication? 2. Is this for the administrative purposes only? 7.1.1.1.2 Config NC Root 7.1.1.1.3 Schema NC Root 7.1.1.1.4 Domain NC Root In order for D2 to replicate the NC, D2 must be granted the following rights on the NC root... 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Status: CAR - ldap display specifiers (SRX090713600122)
You are very welcome Andrew! I am *overflowing* with satisfaction on being able to deliver the goods. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, September 10, 2009 6:30 PM To: Bill Wesse Cc: tri...@samba.org; m...@samba.org; cifs-proto...@samba.org; Hongwei Sun Subject: RE: Status: [cifs-protocol] CAR - ldap display specifiers (SRX090713600122) On Thu, 2009-09-10 at 18:51 +, Bill Wesse wrote: Hello again Andrew - here are the updated display specifier files (Intellectual Property Rights Notice text commented out, per RFC2849). Please let me know if we have satisfied all of your requests; if so, I will consider the case resolved. I think so. 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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
Good morning Andrew - just checking in to see if we have covered everything! -Original Message- From: Hongwei Sun Sent: Wednesday, September 02, 2009 5:10 PM To: 'Andrew Bartlett'; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) Andrew, We confirmed that Windows server 2008 and later systems addressed the problem by implementing validation of the DNSHostName and SPN in NetrLogonGetDomainInfo to enforce the same constraints as specified in section 3.1.1.5.3.1.1.2(dNSHostName) and 3.1.1.5.3.1.1.4(servicePrincipalName) in MS-ADTS. Therefore you should follow these rules to match the Windows behaviors. Please let us know if you have further questions. Thanks! Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 - 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, August 28, 2009 10:53 AM To: 'Andrew Bartlett' Cc: 'cifs-proto...@samba.org'; 'p...@tridgell.net'; 'Matthias Dieter Wallnöfer'; Hongwei Sun Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) I will be out of the office on vacation, returning Monday, September 7. My colleague, Hongwei Sun will be your contact during my absence. 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, August 28, 2009 7:27 AM To: 'Andrew Bartlett' Cc: cifs-proto...@samba.org; p...@tridgell.net; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) Thanks for the information Andrew; I have proposed we add additional NetrLogonGetDomainInfo coverage to our test suites. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, August 27, 2009 5:44 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Wed, 2009-08-26 at 09:52 -0700, Bill Wesse wrote: Hello again Andrew - I have a 'short' answer for you. Windows 2008 does the following additional checks: 1. NETLOGON_WORKSTATION_INFO.DnsHostName and ComputerName match appropriately (re: trailing '$' on ComputerName) 2. NETLOGON_WORKSTATION_INFO.DnsHostName suffix is checked against msDS-AllowedDNSSuffixes. I can't at the moment be more complete, without exercising NetrLogonGetDomainInfo against 2000, 2003 and so on. I hesitate to attempt a description against code hand-checks, as it is just too easy to miss something. Do you have any test software already configured to do that? You could hack the GetDomainInfo test in smbtorture's RPC-NETLOGON. We don't have anything that lets you set it arbitrarily from the command line (yet, I could write it). Andrew Bartlett -- Andrew Bartlett http://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
Re: [cifs-protocol] Status: CAR - ldap display specifiers (SRX090713600122)
I regret that the documents couldn't be delivered in the time frame I gave you - and apologize for not updating you on progress earlier this week. Everyone I've worked with here concerning the document delivery dislikes delays. Even when necessary/obligatory diligence interferes. I have to defer to Hongwei for the next step. Have a great weekend all! 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, August 28, 2009 5:46 PM To: Bill Wesse Cc: tri...@samba.org; m...@samba.org; cifs-proto...@samba.org; Hongwei Sun Subject: RE: Status: [cifs-protocol] CAR - ldap display specifiers (SRX090713600122) On Fri, 2009-08-28 at 07:48 -0700, Bill Wesse wrote: I will be out of the office on vacation, returning Monday, September 7. My colleague, Hongwei Sun will be your contact during my absence. Thanks for the heads up. But over a week ago you promised: Good morning - and thanks for your patience. We are nearly complete with the property rights notice for the display specifiers ldf. I expect to be able to make the final documents available to you within 3-5 working days! I realise there is little you can do while you wait on lawyers, but I'm worried worried: Will the delay be this long every time we try to clarify the release of this kind of thing? (And we are yet to tell if the final form of the documents will be suitable - legally or technically!). Thanks, Andrew Bartlett -- Andrew Bartlett http://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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
Thanks for the information Andrew; I have proposed we add additional NetrLogonGetDomainInfo coverage to our test suites. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, August 27, 2009 5:44 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Wed, 2009-08-26 at 09:52 -0700, Bill Wesse wrote: Hello again Andrew - I have a 'short' answer for you. Windows 2008 does the following additional checks: 1. NETLOGON_WORKSTATION_INFO.DnsHostName and ComputerName match appropriately (re: trailing '$' on ComputerName) 2. NETLOGON_WORKSTATION_INFO.DnsHostName suffix is checked against msDS-AllowedDNSSuffixes. I can't at the moment be more complete, without exercising NetrLogonGetDomainInfo against 2000, 2003 and so on. I hesitate to attempt a description against code hand-checks, as it is just too easy to miss something. Do you have any test software already configured to do that? You could hack the GetDomainInfo test in smbtorture's RPC-NETLOGON. We don't have anything that lets you set it arbitrarily from the command line (yet, I could write it). Andrew Bartlett -- Andrew Bartlett http://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
Re: [cifs-protocol] Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128)
Good morning! I will be out of the office on vacation, returning Monday, September 7. My colleague, Hongwei Sun will be your contact during my absence. We expect to have the updated document change information soon. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Tuesday, August 25, 2009 9:18 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer Subject: RE: Status: Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090713600128) On Tue, 2009-08-25 at 07:17 -0700, Bill Wesse wrote: Thanks again for your input; my response interpolated below... Good morning Andrew - I have attached a pdf showing the changes that will be in the next update to [MS-NRPC] concerning section 2.2.1.3.6 NETLOGON_WORKSTATION_INFO OsVersion field description. These changes will reference [MS-RPRN], which has a full definition for the OSVERSIONINFOEX structure; I have provided a link for this: [MS-RPRN]: Print System Remote Protocol Specification 2.2.3.10.2 OSVERSIONINFOEX http://msdn.microsoft.com/en-us/library/cc669279.aspx 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! While the proposed changes remove the outright incorrect information, I don't see how they help us populate the operatingSystemVersion attribute. The references to the update, and the rules by which it is processed need to be corrected rather than just removed. I'm not sure I understand what is not specified in '[MS-RPRN] 2.2.3.10.2 OSVERSIONINFOEX'. After running down the links in that topic, I see they contain essentially the same information as the MSDN 'OSVERSIONINFOEX Structure' (link shown below, not included in the doc, since we cannot cite MSDN content as normative). OSVERSIONINFOEX Structure http://msdn.microsoft.com/en-us/library/ms724833.aspx Could you elaborate on what sort of processing you are referring to (beyond the implicit matching between the OsName text and OsVersion structured data)? No, it is the removal of the explanation of how the OS version specified here is translated into the operatingSystemVersion attribute, and how/when that is done that seems to have been removed. Andrew Bartlett -- Andrew Bartlett http://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
Re: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015)
Good morning Andrew. Thanks for your feedback. I have interpolated available information below. Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies. The actual Windows behavior is - as Matthias noted previously - that NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4). OK, When will this security bug be addressed? I thought I saw a difference in this behaviour for Windows 2008 - honestly I was expecting 'Windows 2008 fixed this' as your reply. This is currently 'work-in-progress', and I will update you as soon as I have information. My understanding is that this is not an issue with releases after Windows 2003 (which matches with your comments concerning Windows 2008). We are currently working on which document this should be addressed in ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct place, since SPN validation is carried out by Active Directory, outside the scope of the NetLogon protocol. I do not yet have any information concerning whether or not any product bugs will be filed, but I have alerted the appropriate folks here at Microsoft. That may impact any forthcoming Windows Behavior notes. OK. I would appreciate an update on what the expected long-term behaviour of Microsoft products will be, so we know what we must emulate. (Oh the joys of bug-for-bug compatibility) Some of this will depend on Windows 2003 and earlier bug/fix details. I will keep you advised! Thanks for the detail. I look forward to being able to use it some day :-) My pleasure! 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Monday, August 24, 2009 7:30 PM To: Bill Wesse Cc: cifs-proto...@samba.org; p...@tridgell.net; Matthias Dieter Wallnöfer Subject: RE: [cifs-protocol] Please clarify LSA and OsVersion behaviour in MS-NRPC (SRX090727600015) On Mon, 2009-08-24 at 07:35 -0700, Bill Wesse wrote: Andrew - I think I might have missed a previous email of yours. If so, I offer my apologies. The actual Windows behavior is - as Matthias noted previously - that NetrLogonGetDomainInfo bypasses the servicePrincipalName constraints (which are documented in [MS-ADTS] 3.1.1.5.3.1.1.4). OK, When will this security bug be addressed? I thought I saw a difference in this behaviour for Windows 2008 - honestly I was expecting 'Windows 2008 fixed this' as your reply. We are currently working on which document this should be addressed in ([MS-ADTS] or [MS-NRPC]). I expect that [MS-NRPC] is not the correct place, since SPN validation is carried out by Active Directory, outside the scope of the NetLogon protocol. I do not yet have any information concerning whether or not any product bugs will be filed, but I have alerted the appropriate folks here at Microsoft. That may impact any forthcoming Windows Behavior notes. OK. I would appreciate an update on what the expected long-term behaviour of Microsoft products will be, so we know what we must emulate. (Oh the joys of bug-for-bug compatibility) [MS-ADTS]: Active Directory Technical Specification 3.1.1.5.3.1.1.4 servicePrincipalName The object has class computer (or a subclass of computer). In AD DS, the servicePrincipalName value satisfies the following constraints: o The SPN is a syntactically correct two-part SPN (see section 5.1.1.4, Mutual Authentication). o The instance name matches one of the following: the full DNS name of the machine, the sAMAccountName of the machine (without the terminating $), one of the msDS-AdditionalDnsHostName, or one of the msDS-AdditionalSamAccountName (without the terminating $). The guidance I provided earlier addresses these constraints; I regret omitting the reference to [MS-ADTS] 3.1.1.5.3.1.1.4 servicePrincipalName. Before updating the servicePrincipalName attribute (HOST/dNSHostName) for the account under the established secure channel, the following checks would be prudent: Reference: [MS-ADA3]: Active Directory Schema Attributes N-Z 2.252 Attribute servicePrincipalName 1. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account sAMAccountName attribute (minus the trailing '$' character) for the account under the established secure channel. Reference: [MS-ADA3]: Active Directory Schema Attributes N-Z 2.221 Attribute sAMAccountName 2. NETLOGON_WORKSTATION_INFO.DnsHostName must match the client (machine) account dNSHostName attribute for the account under the established secure channel. Reference: [MS-ADA1]: Active Directory Schema Attributes A-L 2.185 Attribute dNSHostName 3
[cifs-protocol] Status: CAR - ldap display specifiers (SRX090713600122)
Good morning - and thanks for your patience. We are nearly complete with the property rights notice for the display specifiers ldf. I expect to be able to make the final documents available to you within 3-5 working days! 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, July 20, 2009 9:31 AM To: 'Andrew Bartlett' Cc: tri...@samba.org; m...@samba.org; cifs-proto...@samba.org Subject: RE: [cifs-protocol] CAR - ldap display specifiers Good morning Andrew! There is no copyright license for the attachments - yet; nevertheless, I expect the below text - or something like it - to apply. I cannot guarantee there will be no changes between now and when the CAR request is fulfilled. I certainly expect this will not take as long as it did with the schema. Intellectual Property Rights Notice for Open Specifications Documentation o Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. o Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL's, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. o No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. o Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft's Open Specification Promise (available here: http://www.microsoft.com/interop/osp) or the Community Promise (available here: http://www.microsoft.com/interop/cp/default.mspx). If you would prefer a written license, or if the technologies described n the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting i...@microsoft.com. o Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise. o Tools. The Open Specifications do not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments you are free to take advantage of them. Certain Open Specifications are intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it. 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: Andrew Bartlett [mailto:abart...@samba.org] Sent: Monday, July 20, 2009 7:15 AM To: Bill Wesse Cc: tri...@samba.org; m...@samba.org; cifs-proto...@samba.org Subject: Re: [cifs-protocol] CAR - ldap display specifiers On Mon, 2009-07-20 at 18:15 +1000, Andrew Bartlett wrote: On Fri, 2009-07-17 at 07:38 -0700, Bill Wesse wrote: Tridge - every out of band release has a unique Intellectual Property notice. So the notice that was included in the schema is unique, and pertains only to the schema release that we provided (it can be obtained on the 'Microsoft Open Specification Support Team Blog' blog at): Using the Windows Server Protocols documentation set to better understand the Active Directory Schema http://blogs.msdn.com/openspecification/archive/2009/06/26/using-the -windows-server-protocols-documentation-set-to-better-understand-the -active-directory-schema.aspx Once document development has detailed the precise nature of the final data
Re: [cifs-protocol] Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights
You are very welcome. I did anticipate future questions – especially concerning Windows 2008 R2 – which is not yet documented. I will be ready and willing to provide that information once we begin posting the Open Specification updates for R2. By the way, the document is not part of the Open Specification documents, so it is not subject to support as such; I am waiting on clearance to post it on the ‘Microsoft Open Specification Support Team Blog’ at http://blogs.msdn.com/OpenSpecification/. It has been a pleasure serving you in this matter! 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: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, August 12, 2009 5:23 AM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Hi, Thank you for the provided document. This infoirmation appears enough for the time being, though I think we may be sending additional questions about specific access rights in the future. Regards, Nadezhda Ivanova - Original Message - From: Bill Wesse bil...@microsoft.com To: Nadezhda Ivanova nadezhda.ivan...@postpath.com Cc: p...@tridgell.net p...@tridgell.net, cifs-proto...@samba.org cifs-proto...@samba.org Sent: Tuesday, August 11, 2009 5:13:24 PM GMT+0200 Europe;Athens Subject: RE: Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Thanks for your patience! I have attached ‘Control Access Rights Concordance.pdf’, which contains all MSDN and Open Specification references with request to network APIs, Active Directory objects, and so on applicable to the control access rights documented in [MS-ADTS]. Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. 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: Tuesday, August 11, 2009 9:08 AM To: 'Nadezhda Ivanova' Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Sorry for the late response; the materials are currently under review – and I expect to be able send the content to you within a few hours. 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: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Tuesday, August 11, 2009 6:28 AM To: Bill Wesse; Nadezhda Ivanova Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Hi, I was wandering if there is any progress on this issue? I did not receive anything yesterday… Regards, Nadezhda Ivanova From: Bill Wesse Sent: Thursday, August 06, 2009 8:30 PM To: Nadezhda Ivanova Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Good afternoon – I have collected most of the references and functions related to the Control Access Rights. I estimate being able to deliver preliminary information next Monday, August 10. 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, August 05, 2009 8:58 AM To: Nadezhda Ivanova Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Good morning again Nadezhda – I will be your contact for this case, and will begin working on collecting the answers this morning. I will contact you as soon as I have some results, or within 1 working day 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: Bill Wesse Sent: Wednesday, August 05, 2009 8:42 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: More information needed about Control Access Rights im MS-ADTS Good morning! Thanks for your question regarding [MS-ADTS]. I have created case SRX090805600011 to track our work against this. One of my colleagues will take ownership of the case and contact you shortly. 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
Re: [cifs-protocol] Explain not standard behaviour of Windows 2003 server
Good evening! Thanks for your question about [MS-LSAD] TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES. I have created case SRX090808600017 to track our work against your request. One of my team members will take ownership of this case and will be in contact with you on Monday (August 10). 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 -Original Message- From: Matthieu Patou [mailto:m...@matws.net] Sent: Saturday, August 08, 2009 2:55 PM To: p...@tridgell.net; Interoperability Documentation Help; cifs-proto...@samba.org Subject: Explain not standard behaviour of Windows 2003 server Hello, In MS-NRPC for response to GetDomainInfo the DC usually return a NETLOGON_DOMAIN_INFO structure. This stucture as explained in 2.2.1.3.11 contains a field called SupportedEncTypes. This field is definied like this: SupportedEncTypes: A set of bit flags that specify the encryption types supported, as specified in [MS-LSAD] section 2.2.7.18. See [MS-LSAD] for a specification of these bit values and their allowed combinations. Looking at MS-LSAD we can learn that the 5th lower bit have the following meaning: C: Supports CRC32, as specified in [RFC3961] page 31. M: Supports RSA-MD5, as specified in [RFC3961] page 31. R: Supports RC4-HMAC-MD5, as specified in [RFC4757]. A: Supports HMAC-SHA1-96-AES128, as specified in [RFC3961] page 31. S: Supports HMAC-SHA1-96-AES256, as specified in [RFC3961] page 31. All other bits SHOULD be 0 and ignored upon receipt. We can reasonably expect that a freshly installed windows 2003 server DC will have bit R set (RC4-HMAC-MD5). Unfortunately it's not the case see at 0x00a4 the field is completely null 83 65 6d 02 2a 9a 4b f2 00 02 00 00 01 00 00 00 .em.*.K. 0010 00 00 02 00 0c 00 0e 00 04 00 02 00 16 00 18 00 0020 08 00 02 00 16 00 18 00 0c 00 02 00 f7 ed 67 20 ..g 0030 9d ca e0 4d a2 51 d9 86 a4 f0 16 24 10 00 02 00 ...M.Q.$ 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070 01 00 00 00 14 00 02 00 00 00 00 00 00 00 00 00 0080 28 00 2a 00 28 00 02 00 00 00 00 00 00 00 00 00 (.*.(... 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 07 00 00 00 00 00 00 00 06 00 00 00 4d 00 53 00 M.S. 00c0 57 00 32 00 4b 00 33 00 0c 00 00 00 00 00 00 00 W.2.K.3. 00d0 0b 00 00 00 6d 00 73 00 77 00 32 00 6b 00 33 00 m.s.w.2.k.3. 00e0 2e 00 74 00 73 00 74 00 2e 00 c5 54 0c 00 00 00 ..t.s.tT 00f0 00 00 00 00 0b 00 00 00 6d 00 73 00 77 00 32 00 m.s.w.2. 0100 6b 00 33 00 2e 00 74 00 73 00 74 00 2e 00 9e fe k.3...t.s.t. 0110 04 00 00 00 01 04 00 00 00 00 00 05 15 00 00 00 0120 86 ec 41 48 9a 49 bf 58 d1 8f f7 2b 01 00 00 00 ..AH.I.X...+ 0130 0c 00 0e 00 18 00 02 00 14 00 16 00 1c 00 02 00 0140 00 00 00 00 00 00 00 00 f7 ed 67 20 9d ca e0 4d ..g ...M 0150 a2 51 d9 86 a4 f0 16 24 20 00 02 00 10 00 10 00 .Q.$ ... 0160 24 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 $... 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 0190 00 00 00 00 06 00 00 00 4d 00 53 00 57 00 32 00 M.S.W.2. 01a0 4b 00 33 00 0b 00 00 00 00 00 00 00 0a 00 00 00 K.3. 01b0 6d 00 73 00 77 00 32 00 6b 00 33 00 2e 00 74 00 m.s.w.2.k.3...t. 01c0 73 00 74 00 04 00 00 00 01 04 00 00 00 00 00 05 s.t. 01d0 15 00 00 00 86 ec 41 48 9a 49 bf 58 d1 8f f7 2b ..AH.I.X...+ 01e0 08 00 00 00 00 00 00 00 08 00 00 00 0d 00 00 00 01f0 00 00 00 00 02 00 00 00 00 00 00 00 15 00 00 00 0200 00 00 00 00 14 00 00 00 73 00 6d 00 62 00 61 00 s.m.b.a. 0210 73 00 76 00 7a 00 30 00 34 00 2e 00 6d 00 73 00 s.v.z.0.4...m.s. 0220 77 00 32 00 6b 00 33 00 2e 00 74 00 73 00 74 00 w.2.k.3...t.s.t. 0230 00 00 00 00 With a windows 2008 server it's not better because I have 0x. Can you explain this situation ? Thanks. Matthieu Patou. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights
Good afternoon - I have collected most of the references and functions related to the Control Access Rights. I estimate being able to deliver preliminary information next Monday, August 10. 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, August 05, 2009 8:58 AM To: Nadezhda Ivanova Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights Good morning again Nadezhda - I will be your contact for this case, and will begin working on collecting the answers this morning. I will contact you as soon as I have some results, or within 1 working day 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: Bill Wesse Sent: Wednesday, August 05, 2009 8:42 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: More information needed about Control Access Rights im MS-ADTS Good morning! Thanks for your question regarding [MS-ADTS]. I have created case SRX090805600011 to track our work against this. One of my colleagues will take ownership of the case and contact you shortly. 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: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, August 05, 2009 5:16 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: More information needed about Control Access Rights im MS-ADTS Hi, Section 5.1.3.2.1 of MS-ADTS contains a table with the supported Control Access Rights and the corresponding GUIDs. Is there any information in the documents about each of these rights, namely: When are these rights assigned to an object? Is it done by the system in response to an event or configuration? What each of them means form a user's point of view, and at what event is an access check for such a right actually performed? Regards, Nadezhda Ivanova [cid:image001.gif@01CA1699.FD0F82E0] Nadezhda Ivanova Software Engineer Software Development nadezhda.ivan...@postpath.commailto:nadezhda.ivan...@postpath.com CISCO SYSTEMS BULGARIA EOOD 18 Macedonia Blvd. Sofia 1606 Bulgaria Cisco home pagehttp://www.cisco.com/global/BG/ [cid:image002.gif@01CA1699.FD0F82E0]Think before you print. inline: image001.gifinline: image002.gif___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SRX090805600011 : [MS-ADTS] 5.1.3.2.1 Control Access Rights
Good morning again Nadezhda - I will be your contact for this case, and will begin working on collecting the answers this morning. I will contact you as soon as I have some results, or within 1 working day 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: Bill Wesse Sent: Wednesday, August 05, 2009 8:42 AM To: Nadezhda Ivanova; Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: More information needed about Control Access Rights im MS-ADTS Good morning! Thanks for your question regarding [MS-ADTS]. I have created case SRX090805600011 to track our work against this. One of my colleagues will take ownership of the case and contact you shortly. 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: Nadezhda Ivanova [mailto:nadezhda.ivan...@postpath.com] Sent: Wednesday, August 05, 2009 5:16 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: More information needed about Control Access Rights im MS-ADTS Hi, Section 5.1.3.2.1 of MS-ADTS contains a table with the supported Control Access Rights and the corresponding GUIDs. Is there any information in the documents about each of these rights, namely: When are these rights assigned to an object? Is it done by the system in response to an event or configuration? What each of them means form a user's point of view, and at what event is an access check for such a right actually performed? Regards, Nadezhda Ivanova [cid:image001.gif@01CA15AA.E6ACD330] Nadezhda Ivanova Software Engineer Software Development nadezhda.ivan...@postpath.commailto:nadezhda.ivan...@postpath.com CISCO SYSTEMS BULGARIA EOOD 18 Macedonia Blvd. Sofia 1606 Bulgaria Cisco home pagehttp://www.cisco.com/global/BG/ [cid:image002.gif@01CA15AA.E6ACD330]Think before you print. inline: image001.gifinline: image002.gif___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] CAR - ldap display specifiers
You're completely welcome. The notice in the schema is not exactly the same as what is in our current document postings. For the moment, however, the below text is the notice I have been advised should apply. I will ask for additional clarification on this today, since I think it would be *not a good idea* to make any assumptions about, given the textual discrepancies between the below and that provided in the schema. Intellectual Property Rights Notice for Open Specifications Documentation o Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. o Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL's, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. o No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. o Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft's Open Specification Promise (available here: http://www.microsoft.com/interop/osp) or the Community Promise (available here: http://www.microsoft.com/interop/cp/default.mspx). If you would prefer a written license, or if the technologies described n the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting i...@microsoft.com. o Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise. o Tools. The Open Specifications do not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments you are free to take advantage of them. Certain Open Specifications are intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it. 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: tri...@samba.org [mailto:tri...@samba.org] Sent: Friday, July 17, 2009 5:39 AM To: Bill Wesse Cc: cifs-proto...@samba.org; m...@samba.org Subject: RE: CAR - ldap display specifiers Hi Bill, Thanks for the LDIF! Can we assume the license on this is the same as for the schema? For the schema the version we got from MS had the license at the top, which you can see here: For the schema license, see this: http://samba.org/ftp/unpacked/samba_4_0_test/source4/setup/ad-schema/MS-AD_Schema_2K8_Classes.txt I'm pretty sure you intend us to just use the same license, but I thought I should check. Cheers, Tridge ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] CAR - ldap display specifiers
Tridge - every out of band release has a unique Intellectual Property notice. So the notice that was included in the schema is unique, and pertains only to the schema release that we provided (it can be obtained on the 'Microsoft Open Specification Support Team Blog' blog at): Using the Windows Server Protocols documentation set to better understand the Active Directory Schema http://blogs.msdn.com/openspecification/archive/2009/06/26/using-the-windows-server-protocols-documentation-set-to-better-understand-the-active-directory-schema.aspx Once document development has detailed the precise nature of the final data we will be supplying, an IP notice will be attached! 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, July 17, 2009 7:18 AM To: 'tri...@samba.org' Cc: cifs-proto...@samba.org; m...@samba.org Subject: RE: CAR - ldap display specifiers You're completely welcome. The notice in the schema is not exactly the same as what is in our current document postings. For the moment, however, the below text is the notice I have been advised should apply. I will ask for additional clarification on this today, since I think it would be *not a good idea* to make any assumptions about, given the textual discrepancies between the below and that provided in the schema. Intellectual Property Rights Notice for Open Specifications Documentation o Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. o Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL's, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. o No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. o Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft's Open Specification Promise (available here: http://www.microsoft.com/interop/osp) or the Community Promise (available here: http://www.microsoft.com/interop/cp/default.mspx). If you would prefer a written license, or if the technologies described n the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting i...@microsoft.com. o Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise. o Tools. The Open Specifications do not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments you are free to take advantage of them. Certain Open Specifications are intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it. 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: tri...@samba.org [mailto:tri...@samba.org] Sent: Friday, July 17, 2009 5:39 AM To: Bill Wesse Cc: cifs-proto...@samba.org; m...@samba.org Subject: RE: CAR - ldap display specifiers Hi Bill, Thanks for the LDIF! Can we assume the license on this is the same as for the schema? For the schema the version we got from MS had the license at the top, which you can see here: For the schema license, see this: http://samba.org/ftp/unpacked/samba_4_0_test
[cifs-protocol] RE: Please clarify LSA and OsVersion behaviour in MS-NRPC
.. WORD
wServicePackMajor 0x0002 (2) 2.0
025600 00.. WORD
wServicePackMinor 0x (0)
0257 00 01.. WORD
wSuiteMask0x0100 (256) VER_SUITE_SINGLEUSERTS
025701 . BYTE
wProductType0x01 (1) VER_NT_WORKSTATION
0258 00 .BYTE
wReserved 0x00 (0)
NTSTATUS NetrLogonGetDomainInfo(
[in, string] LOGONSRV_HANDLE ServerName,
[in, string, unique] wchar_t* ComputerName,
[in] PNETLOGON_AUTHENTICATOR Authenticator,
[in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator,
[in] DWORD Level,
[in, switch_is(Level)] PNETLOGON_WORKSTATION_INFORMATION WkstaBuffer,
[out, switch_is(Level)] PNETLOGON_DOMAIN_INFORMATION DomBuffer
);
1E 00 00 00 00 00 00 00 1E 00 00 00 5C 00 5C 00 \.\.
0010 6E 00 61 00 6F 00 6D 00 69 00 2E 00 53 00 34 00 n.a.o.m.i...S.4.
0020 2E 00 4E 00 41 00 4F 00 4D 00 49 00 2E 00 41 00 ..N.A.O.M.I...A.
0030 42 00 41 00 52 00 54 00 4C 00 45 00 54 00 2E 00 B.A.R.T.L.E.T...
0040 4E 00 45 00 54 00 00 00 08 5E 17 00 08 00 00 00 N.E.T^..
0050 00 00 00 00 08 00 00 00 57 00 49 00 4E 00 58 00 W.I.N.X.
0060 50 00 2D 00 35 00 00 00 4D 20 E4 59 70 FC A2 CE P.-.5...M .Yp...
0070 D5 0D 54 4A 00 00 00 00 00 00 00 00 00 00 00 00 ..TJ
0080 01 00 00 00 01 00 00 00 D0 F4 E6 00 00 00 00 00
0090 00 00 00 00 58 CF 15 00 94 F8 E6 00 00 00 00 00 X...
00A0 00 00 00 00 00 00 00 00 00 00 00 00 1C 01 1C 01
00B0 60 F5 E6 00 2E 00 30 00 80 27 50 74 00 00 00 00 `.0..'Pt
00C0 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
00D0 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
00E0 00 00 00 00 08 00 00 00 77 00 69 00 6E 00 78 00 w.i.n.x.
00F0 70 00 2D 00 35 00 00 00 18 00 00 00 00 00 00 00 p.-.5...
0100 18 00 00 00 44 00 65 00 66 00 61 00 75 00 6C 00 D.e.f.a.u.l.
0110 74 00 2D 00 46 00 69 00 72 00 73 00 74 00 2D 00 t.-.F.i.r.s.t.-.
0120 53 00 69 00 74 00 65 00 2D 00 4E 00 61 00 6D 00 S.i.t.e.-.N.a.m.
0130 65 00 00 00 8E 00 00 00 00 00 00 00 8E 00 00 00 e...
0140 1C 01 00 00 05 00 00 00 01 00 00 00 28 0A 00 00 (...
0150 02 00 00 00 53 00 65 00 72 00 76 00 69 00 63 00 S.e.r.v.i.c.
0160 65 00 20 00 50 00 61 00 63 00 6B 00 20 00 32 00 e. .P.a.c.k. .2.
0170 00 00 E6 00 02 00 00 00 00 00 00 00 20 C0 0B 00 ...
0180 40 5A 86 5B 00 00 00 00 00 00 00 00 00 00 00 00 @Z.[
0190 30 00 09 00 02 00 00 00 00 00 00 00 00 00 00 00 0...
01A0 B0 E4 E6 00 00 00 00 00 00 00 00 00 00 00 00 00
01B0 00 00 00 00 C4 F5 E6 00 0E 00 00 00 00 00 00 00
01C0 D0 E4 E6 00 20 F6 E6 00 00 00 00 00 00 00 00 00 ...
01D0 00 00 00 00 0D 00 00 00 58 61 17 00 4F 00 00 00 Xa..O...
01E0 00 00 00 00 00 00 09 00 1A 00 00 00 00 00 00 00
01F0 00 00 00 00 00 00 00 00 20 C0 0B 00 00 00 00 00 ...
0200 04 5D 88 8A 48 00 00 00 CC 27 87 5B BC 27 87 5B .]..H'.[.'.[
0210 09 00 00 00 DA 27 87 5B D0 F8 E6 00 00 00 00 00 .'.[
0220 00 00 00 00 C6 27 87 5B DA 5A 86 5B 00 00 00 00 .'.[.Z.[
0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0240 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $...
0250 00 00 00 00 02 00 00 00 00 01 01 00 18 00 00 00
0260 00 00 00 00 17 00 00 00 57 00 69 00 6E 00 64 00 W.i.n.d.
0270 6F 00 77 00 73 00 20 00 58 00 50 00 20 00 50 00 o.w.s. .X.P. .P.
0280 72 00 6F 00 66 00 65 00 73 00 73 00 69 00 6F 00 r.o.f.e.s.s.i.o.
0290 6E 00 61 00 6C 00 00 00 8A E3 13 71 02 F4 36 71 n.a.l..q..6q
02A0 01 40 04 00 01 00 00 00- @..*
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: Andrew Bartlett [mailto:abart...@samba.org]
Sent: Tuesday, July 07, 2009 11:45 PM
To: Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org; Matthias Dieter Wallnöfer
Subject: Please clarify LSA and OsVersion behaviour in MS-NRPC
In MS-NRPC 2.2.1.3.6 NETLOGON_WORKSTATION_INFO it has:
typedef struct _NETLOGON_WORKSTATION_INFO {
NETLOGON_LSA_POLICY_INFO LsaPolicy;
This is defined in 2.2.1.3.5, but not very helpfully:
The NETLOGON_LSA_POLICY_INFO structure defines Local Security
Authority (LSA) policy information as an unsigned character buffer. For
details, see [LSAPOLICY] and [MS-LSAD].
My question is: Is this buffer ever filled in (it is null in the attached
example
[cifs-protocol] Resend: [Pfif] erroneous references to little-endian (SRX090617600092)
Good day! I am resending this, as I have not received a response from you. Hope
you are doing well.
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, June 23, 2009 6:08 AM
To: Steve French
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: RE: [Pfif] erroneous references to little-endian (SRX090617600092)
Good morning once again - and thanks for your patience.
Unlike the [MS-SMB] SMB_COM_SESSION_SETUP_ANDX, [MS-SMB2] SESSION_SETUP does
not contain 'NativeOS (variable)' and 'NativeLANMan (variable)' string fields.
For the sake of completeness, as you no doubt are already familiar with, the
security 'Buffer (variable)' will contain this information. For 'Implicit NTLM'
(raw NTLMSSP), or NTLM tokens embedded in GSS-API, the NEGOTIATE_MESSAGE,
AUTHENTICATE_MESSAGE and AUTHENTICATE_MESSAGE AV_PAIR and Version fields (as
described in [MS-NLMP]). Kerberos [MS-KILE] is, of course, a different beast
entirely. The KRB_AP_REQ Ticket contains the Realm and Sname. The Privilege
Attribute Certificate Structure [MS-PAC] contains the PAC_CLIENT_INFO
structure, and so on, as documented in {MS-KILE].
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, June 17, 2009 11:26 AM
To: Steve French; Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: RE: [Pfif] erroneous references to little-endian (SRX090617600092)
Good morning Mr. French. Thank you for reporting the OS and NOS string
documentation shortcomings in [MS-SMB2].
I have created case SRX090617600092 for your comments concerning that, and
expect to begin work on this later today, or tomorrow morning at the latest.
I confirm that a documentation change is currently pending (work in progress)
against the raw ('Implicit NTLM') NTLMSSP buffer content. I will be glad to
update you when we have the final text ready.
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: Steve French [mailto:smfre...@gmail.com]
Sent: Wednesday, June 17, 2009 9:14 AM
To: Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [Pfif] erroneous references to little-endian
In implementing SMB2 Session Setup protocol support I did not notice
reference to the OS and NOS (the strings which name the operating
system and network operating system version fields of the client and
server) which followed the security blob. See sections 2.2.5 and
2.2.6 of MS-SMB2 and 3.3.5.5.The description of the buffer field
just notes that it MUST contain a token as produced by the GSS
protocol as specified in section 3.2.5.3 (which would not describe
the operating system or network operating system fields). Note that
an earlier CAR shows that the description of the buffer field is
incorrect in another way (Windows servers accept NTLMSSP, not
encapsulated in GSS in the buffer field for SMB2, and in some ways
that is easier and safer to generate).
--
Thanks,
Steve
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] erroneous references to little-endian (SRX090617600092)
Good morning once again - and thanks for your patience.
Unlike the [MS-SMB] SMB_COM_SESSION_SETUP_ANDX, [MS-SMB2] SESSION_SETUP does
not contain 'NativeOS (variable)' and 'NativeLANMan (variable)' string fields.
For the sake of completeness, as you no doubt are already familiar with, the
security 'Buffer (variable)' will contain this information. For 'Implicit NTLM'
(raw NTLMSSP), or NTLM tokens embedded in GSS-API, the NEGOTIATE_MESSAGE,
AUTHENTICATE_MESSAGE and AUTHENTICATE_MESSAGE AV_PAIR and Version fields (as
described in [MS-NLMP]). Kerberos [MS-KILE] is, of course, a different beast
entirely. The KRB_AP_REQ Ticket contains the Realm and Sname. The Privilege
Attribute Certificate Structure [MS-PAC] contains the PAC_CLIENT_INFO
structure, and so on, as documented in {MS-KILE].
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, June 17, 2009 11:26 AM
To: Steve French; Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: RE: [Pfif] erroneous references to little-endian (SRX090617600092)
Good morning Mr. French. Thank you for reporting the OS and NOS string
documentation shortcomings in [MS-SMB2].
I have created case SRX090617600092 for your comments concerning that, and
expect to begin work on this later today, or tomorrow morning at the latest.
I confirm that a documentation change is currently pending (work in progress)
against the raw ('Implicit NTLM') NTLMSSP buffer content. I will be glad to
update you when we have the final text ready.
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: Steve French [mailto:smfre...@gmail.com]
Sent: Wednesday, June 17, 2009 9:14 AM
To: Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [Pfif] erroneous references to little-endian
In implementing SMB2 Session Setup protocol support I did not notice
reference to the OS and NOS (the strings which name the operating
system and network operating system version fields of the client and
server) which followed the security blob. See sections 2.2.5 and
2.2.6 of MS-SMB2 and 3.3.5.5.The description of the buffer field
just notes that it MUST contain a token as produced by the GSS
protocol as specified in section 3.2.5.3 (which would not describe
the operating system or network operating system fields). Note that
an earlier CAR shows that the description of the buffer field is
incorrect in another way (Windows servers accept NTLMSSP, not
encapsulated in GSS in the buffer field for SMB2, and in some ways
that is easier and safer to generate).
--
Thanks,
Steve
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] erroneous references to little-endian (SRX090617600092)
Good morning Mr. French. Thank you for reporting the OS and NOS string
documentation shortcomings in [MS-SMB2].
I have created case SRX090617600092 for your comments concerning that, and
expect to begin work on this later today, or tomorrow morning at the latest.
I confirm that a documentation change is currently pending (work in progress)
against the raw ('Implicit NTLM') NTLMSSP buffer content. I will be glad to
update you when we have the final text ready.
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: Steve French [mailto:smfre...@gmail.com]
Sent: Wednesday, June 17, 2009 9:14 AM
To: Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [Pfif] erroneous references to little-endian
In implementing SMB2 Session Setup protocol support I did not notice
reference to the OS and NOS (the strings which name the operating
system and network operating system version fields of the client and
server) which followed the security blob. See sections 2.2.5 and
2.2.6 of MS-SMB2 and 3.3.5.5.The description of the buffer field
just notes that it MUST contain a token as produced by the GSS
protocol as specified in section 3.2.5.3 (which would not describe
the operating system or network operating system fields). Note that
an earlier CAR shows that the description of the buffer field is
incorrect in another way (Windows servers accept NTLMSSP, not
encapsulated in GSS in the buffer field for SMB2, and in some ways
that is easier and safer to generate).
--
Thanks,
Steve
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] [MS-SMB2] Error in SMB2 Netprot description. SRX090604600250, SRX090604600324, SRX090604600333
Good morning again! We have split the 3 documentation problems you reported into 3 separate cases; this is normal for our issue housekeeping. I will be working all three. Here is a short list, followed by the problem description for each: [MS-SMB2] Error in SMB2 Netprot description: SRX090604600250 [MS-SMB2] SESSION_SETUP Request: SRX090604600324 [MS-SMB2] SMB2 SESSION_SETUP Response: SRX090604600333 == [MS-SMB2] Error in SMB2 Netprot description: SRX090604600250 I believe there is an error in [MS-SMB2] - v20090521 in the description of 2.2.4 SMB2 NEGOTIATE Response. At the end of this section on page 35 it says: Buffer (variable): The variable-length buffer that contains the security buffer for the response, as specified by SecurityBufferOffset and SecurityBufferLength. The buffer MUST contain a token as produced by the GSS protocol as specified in section 3.3.5.3. The MUST statement is incorrect. The Windows client behavior is that if a null buffer is returned in this field, then the client will downgrade to using raw-NTLMSSP blobs for sessionsetup instead of SPNEGO wrapped blobs. I can provide proof of this as a packet trace on request. I think this is important to fix for the SMB2 client implementations, which otherwise are forced to implement SPNEGO ASN.1 parsing. == [MS-SMB2] SESSION_SETUP Request: SRX090604600324 Section 2.2.5 SMB2 SESSION_SETUP Request also has a MUST at the end of the section: Buffer (variable): A variable-length buffer that contains the security buffer for the request, as specified by SecurityBufferOffset and SecurityBufferLength. The buffer MUST contain a token as produced by the GSS protocol as specified in section 3.3.5.5. The values in these buffers can be a raw NTLMSSP data blob instead of a GSS blob. Jeremy Allison, Samba Team/PFIF. == [MS-SMB2] SMB2 SESSION_SETUP Response: SRX090604600333 and also 2.2.6 SMB2 SESSION_SETUP Response has a MUST at the end of the section: Buffer (variable): A variable-length buffer that contains the security buffer for the response, as specified by SecurityBufferOffset and SecurityBufferLength. The buffer MUST contain a token as produced by the GSS protocol as specified in section 3.2.5.3. The values in these buffers can be a raw NTLMSSP data blob instead of a GSS blob. 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: Thursday, June 04, 2009 4:45 PM To: Jeremy Allison Cc: Interoperability Documentation Help; cifs-proto...@samba.org Subject: RE: [Pfif] CAR: Error in SMB2 Netprot description. (SRX090604600250) I neglected to provide you with the case number, which is: SRX090604600250. 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: Thursday, June 04, 2009 4:32 PM To: Jeremy Allison Cc: Interoperability Documentation Help; cifs-proto...@samba.org Subject: RE: [Pfif] CAR: Error in SMB2 Netprot description. Jeremy - thanks for the network capture - I will begin working on this tomorrow morning (Friday, GMT - 5). The [MS-SMB] document (reference below) 3.2.4.2.3 User Authentication 'Implicit NTLM' subsection talks about this; I will cross-compare [MS-SMB2] against this, and proceed with any appropriate document change requests. [MS-SMB]: Server Message Block (SMB) Protocol Specification 3.2.4.2.3 User Authentication http://msdn.microsoft.com/en-us/library/cc246379(PROT.13).aspx Implicit NTLM 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: Jeremy Allison [mailto:j...@samba.org] Sent: Thursday, June 04, 2009 2:51 PM To: Jeremy Allison Cc: Interoperability Documentation Help; cifs-proto...@samba.org Subject: Re: [Pfif] CAR: Error in SMB2 Netprot description. On Thu, Jun 04, 2009 at 11:39:38AM -0700, Jeremy Allison wrote: On Thu, Jun 04, 2009 at 11:33:41AM -0700, Jeremy Allison wrote: Hi all, I believe there is an error in [MS-SMB2] — v20090521 in the description of 2.2.4 SMB2 NEGOTIATE Response. At the end of this section on page 35 it says: Buffer (variable): The variable-length buffer that contains the security buffer for the response, as specified by SecurityBufferOffset and SecurityBufferLength. The buffer MUST contain a token as produced by the GSS protocol as specified in section
[cifs-protocol] RE: [Pfif] erroneous references to little-endian
Thanks! That change is indeed set for the upcoming release. Nice to work with you again... 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: Steve French [mailto:smfre...@gmail.com] Sent: Thursday, April 30, 2009 1:54 PM To: Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] erroneous references to little-endian On Thu, Apr 30, 2009 at 12:33 PM, Bill Wesse bil...@microsoft.com wrote: Good day once again Mr. French! I have verified that our [MS-SMB] working document has already incorporated the necessary deletion of the DialectCount field (2.2.4). The changes will be available in a future document refresh; notifications concerning protocol documentation updates to the Open Specifications are announced via our Protocols Perspective e-Newsletter. I also checked Network Monitor 3.3 smb2.npl, which has the 'struct SMB2ResponseNegotiate.DialectCount' field defined, and have filed a bug against that. Please read on for further information about this! Thank you very much for bringing this to our attention. Please let me know if this answers your question satisfactorily; so, I will consider your question resolved. Sounds fine. Note that the most recently released (dated 4/11 but only released in last few weeks or less) MS-SMB2.pdf still contains this error, so I will look for it in the May updates. -- Thanks, Steve ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] erroneous references to little-endian
Good day once again Mr. French! I have verified that our [MS-SMB] working
document has already incorporated the necessary deletion of the DialectCount
field (2.2.4). The changes will be available in a future document refresh;
notifications concerning protocol documentation updates to the Open
Specifications are announced via our Protocols Perspective e-Newsletter.
I also checked Network Monitor 3.3 smb2.npl, which has the 'struct
SMB2ResponseNegotiate.DialectCount' field defined, and have filed a bug against
that. Please read on for further information about this!
Thank you very much for bringing this to our attention. Please let me know if
this answers your question satisfactorily; if so, I will consider your question
resolved.
If you haven't already done so, you can subscribe to the newsletter at the
below link:
Receive the Protocols Perspective e-Newsletter
http://www.microsoft.com/protocols/optin.aspx
Each month you'll receive helpful information about:
Protocol Documentation Updates
Patent License Program
Other Licensing Programs
Community Events
Helpful Tips
Licensee Case Studies
==
Network Monitor 3.3 can be obtained at: http://connect.microsoft.com/
%SystemDrive%\ProgramData\Microsoft\Network Monitor 3\NPL\Microsoft
Parsers\Common\smb2.npl
smb2.npl
Line 180:
Modify:
struct SMB2ResponseNegotiate
{
UINT16 Size;
UINT16 DialectCount;
UINT16 SecurityMode = SMB2SecurityMode(this);
UINT16 DialectRevision = SMB2DialectRevisionTable(this);
UINT16 Reserved;
...
Remove:
UINT16 DialectCount;
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, April 28, 2009 5:59 AM
To: Steve French; Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: RE: [Pfif] erroneous references to little-endian
Good morning Mr. French! I have created case SRX09042864 for your question,
and will begin my investigation shortly. I will keep you advised of progress!
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: Steve French [mailto:smfre...@gmail.com]
Sent: Monday, April 27, 2009 9:14 PM
To: Interoperability Documentation Help
Cc: p...@tridgell.net; cifs-proto...@samba.org
Subject: Re: [Pfif] erroneous references to little-endian
In implementing SMB2 Negotiate protocol support I noticed that the
structure definition is off by 2 bytes.
Section 2.2.4 of MS-SMB2.pdf shows the SMB2 negotiate response as an
SMB2 header followed by
le16 StructureSize; /* Must be 65 */
le16 DialectCount;
le16 SecurityMode;
le16 DialectRevision; /* Should be 0x0202 */
... etc
when it actually has no DialectCount which is clear when decoding by
hand (or looking at it in Wireshark)
le16 StructureSize; /* Must be 65 */
le16 SecurityMode;
le16 DialectRevision; /* Should be 0x0202 */
... etc
The server in this case is Vista. The dialect negotiated was 0x0202
in response to an SMB2 only (not SMB) negotiate protocol request.
--
Thanks,
Steve
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: [Pfif] erroneous references to little-endian
Good morning Mr. French! I have created case SRX09042864 for your question, and will begin my investigation shortly. I will keep you advised of progress! 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: Steve French [mailto:smfre...@gmail.com] Sent: Monday, April 27, 2009 9:14 PM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] erroneous references to little-endian In implementing SMB2 Negotiate protocol support I noticed that the structure definition is off by 2 bytes. Section 2.2.4 of MS-SMB2.pdf shows the SMB2 negotiate response as an SMB2 header followed by le16 StructureSize; /* Must be 65 */ le16 DialectCount; le16 SecurityMode; le16 DialectRevision; /* Should be 0x0202 */ ... etc when it actually has no DialectCount which is clear when decoding by hand (or looking at it in Wireshark) le16 StructureSize; /* Must be 65 */ le16 SecurityMode; le16 DialectRevision; /* Should be 0x0202 */ ... etc The server in this case is Vista. The dialect negotiated was 0x0202 in response to an SMB2 only (not SMB) negotiate protocol request. -- Thanks, Steve ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: MS-ERREF addition requested
) // A virtual disk support provider for the specified file was not found. #define STATUS_VIRTDISK_PROVIDER_NOT_FOUND ((NTSTATUS)0xC03A0014L) // The specified disk is not a virtual disk. #define STATUS_VIRTDISK_NOT_VIRTUAL_DISK ((NTSTATUS)0xC03A0015L) // The chain of virtual hard disks is inaccessible. The process has not been granted access rights to the parent virtual hard disk for the differencing disk. #define STATUS_VHD_PARENT_VHD_ACCESS_DENIED ((NTSTATUS)0xC03A0016L) // The chain of virtual hard disks is corrupted. There is a mismatch in the virtual sizes of the parent virtual hard disk and differencing disk. #define STATUS_VHD_CHILD_PARENT_SIZE_MISMATCH ((NTSTATUS)0xC03A0017L) // The chain of virtual hard disks is corrupted. A differencing disk is indicated in its own parent chain. #define STATUS_VHD_DIFFERENCING_CHAIN_CYCLE_DETECTED ((NTSTATUS)0xC03A0018L) // The chain of virtual hard disks is inaccessible. There was an error opening a virtual hard disk further up the chain. #define STATUS_VHD_DIFFERENCING_CHAIN_ERROR_IN_PARENT ((NTSTATUS)0xC03A0019L) 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: zachary.loaf...@isilon.com [mailto:zachary.loaf...@isilon.com] Sent: Tuesday, March 31, 2009 6:35 PM To: Interoperability Documentation Help Cc: cifs-proto...@samba.org; p...@tridgell.net Subject: MS-ERREF addition requested (Resending with CC to dochelp) Win7 build 7000 is sending NT status code 0xC1A1 in response to certain Byte-Range Lock operations, for example the offset = UINT64_MAX, length = UINT64_MAX case. I totally agree with this change, but MS-ERREF does not document 0xC1A1, nor do any public-facing documents that I can find. Can we get this documented? (An example of this can be found in the smbtorture RAW-LOCK test.) -- Zach Loafman | Staff Engineer | Isilon Systems ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status of SRX080902600070 (trusted domains overview) and SRX080909600334 (backing store / policy)
Andrew - I again thank you for your patience, on behalf of myself and our documentation team. SRX080902600070 [MS-ADSO]: LSA and trusted domains overview A document improvement suggestion has been filed against '[MS-ADSO]: Active Directory System Overview' with regards to the 'PasswordPolicyAndValidation.pdf' file I previously provided to you. The improvement suggestion is to include the appropriate information within the overview document. SRX080909600334 [MS-AUTHSO] Backing store and policy application info A document improvement suggestion has been filed against '[MS-AUTHSO]: Windows Authentication Services System Overview' with regards to the [SCENARIO_DOMAIN_TRUST].pdf file I previously provided to you. The improvement suggestion is to include the appropriate information within the overview document. I will follow up this week with an updated [SCENARIO_DOMAIN_TRUST].pdf, containing unencrypted network packet data. I regret I was not previously able to provide the unencrypted packets; I just completed a significant amount of work concerning test hotfix creation, as well as source research to locate encryption control for the various protocols. Unless you indicate otherwise, I will archive the above noted cases. It has been a pleasure serving you in this matter. Thanks for helping us improve our documentation! 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
You are very welcome; I anticipated more detail would go into the document than what did (further delineation in the document would have to go, of necessity, in the Windows Behavior section. Thank you for both your patience, understanding and document improvement feedback. It has been a pleasure serving you. 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: Adam Simpkins [mailto:simpk...@cisco.com] Sent: Wednesday, December 17, 2008 12:56 AM To: Bill Wesse Cc: 'cifs-proto...@samba.org' Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO On Tue, Dec 16, 2008 at 04:06:46AM -0800, Bill Wesse wrote: Good afternoon Mr. Simpkins. Thank you for your patience. We have modified [MS-NLMP] for a future posting, as shown below, to address your comments (which I have also included, for the sake of completeness). Please let me know if this meets your needs. == [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol Specification 3.1.4 Higher-Layer Triggered Events The application client initiates NTLM authentication through the Security Support Provider Interface (SSPI), the Microsoft implementation of GSS-API [RFC2743]. NTLM does not support RFC 2743 token framing (Section 3.1 [RFC2743]). Yes, I think that sufficiently addresses the issue. I think it would have been nice to also mention the implications of this lack of support (how it affects the tokens generated by GSS_Init_sec_context() and the tokens accepted by GSS_Accept_sec_context()), but I'll take what I can get. Thanks for all your help pushing this change through, Bill! -- Adam Simpkins simpk...@cisco.com ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: List of interfaces used by Trusted domains (SRX081021600181)
Good morning again Andrew. As I noted in my other email, I will provide unencrypted network packet contents as soon as I can (I will keep you advised on this). Meanwhile, I have spent considerable time handchecking the source code in various versions of Windows Server (2000 - 2008), in order to profile trust management. In the general case, the same functions are used, but I have not yet collected the version dependant detail differences. I would again like to thank you for your patience; I expect to have a progress update for you next week. Regards, Bill Wesse MCSE, MCTS / 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: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2008 6:17 PM To: Bill Wesse Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: List of interfaces used by Trusted domains (SRX081021600181) On Tue, 2008-10-21 at 09:47 -0700, Bill Wesse wrote: Good morning Andrew. Bill Wesse here again. I have just taken ownership of this case (SRX081021600181), and have already begun work. Please note that the attached document ([SCENARIO_DOMAIN_TRUST].pdf) contains some of the information you are looking for (for external trusts only, at this point). I am currently setting up a virtual machine to house FreeBSD and MIT Kerberos in order to detail the network traffic involved with trust manipulation, and will keep you advised of my progress. Thankyou very much. One note I would make about the packet dumps, which form the majority of this document is that while the cleartext headers are specified in incredible detail, they provide little information. At the same time, the actually useful parts are still encrypted. Perhaps these could be reversed, with the headers excluded (if an implementer can't understand the headers, they should look at the right RPC doc) but the payload in the clear. This would save space, paper and provide more useful information. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Status: SRX081013600536: [MS-NRPC] operation backing store linkages
Good morning Andrew. I am sending this to let you know that I have not yet finished my survey and annotation of the backing store linkages (on a function by function basis). I don't expect to finish this for at least another week. Thanks for your patience! Regards, Bill Wesse MCSE, MCTS / 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 20, 2008 7:20 AM To: 'Andrew Bartlett' Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages Thank you again Andrew. I am proceeding with an enumeration of the linkage list, for submission to document development. Regards, Bill Wesse MCSE, MCTS / 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: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 8:02 AM To: Bill Wesse Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages On Fri, 2008-10-17 at 03:38 -0700, Bill Wesse wrote: Thanks Andrew - especially for the corrections. Just to clarify, the document was never meant to be standalone; It is a very useful thing standalone, or alongside the main document, because it is organised differently, and even just that makes it easier to work with (sometimes it is great to have two different ways to approach the info). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
Thank you very much for your considerations. I have filed a documentation change request against [MS-NLMP] concerning NTLMSSP InitialContextTokens (see 'Expected' below).. == Change Comment / Request: The documentation updates so far have addressed the fact that the Windows implementation accepts raw NTLM SSP tokens that are not correctly embedded in GSS InitialContextTokens. However, I don't recall any updates addressing the fact that the Windows implementation does not accept well-formed GSS InitialContextTokens containing NTLM SSP. This could probably be addressed by updating [MS-NLMP] somewhere to indicate that the NTLM implementation of GSS_Init_sec_context() never outputs a GSS InitialContextToken for the first token, and GSS_Accept_sec_context() does not accept well-formed GSS InitialContextTokens. Updating [MS-NLMP] this way would address both the behavior with and without SPNEGO, since SPNEGO should merely be invoking GSS_Init_sec_context()/GSS_Accept_sec_context() to handle the inner NTLM SSP mechToken. The Universal Receiver section of [MS-SPNG] probably wouldn't even be relevant anymore. I'm not sure where the best place in [MS-NLMP] would be to mention this. Section 1.4 talks about the GSS-API interface to NTLM. It references section 3.4.6, but that only talks about the GSS_WrapEx() call. == Ref: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism http://www.ietf.org/rfc/rfc4178.txt?number=4178 3.2. Negotiation Procedure If the initiator's preferred mechanism is accepted, and an optimistic mechanism token was included, this mechanism token MUST be passed to the selected mechanism by invoking GSS_Accept_sec_context(). GSS_Accept_sec_context() is defined in RFC 2743, and the first token passed to it must use the format specified in section 3.1 (i.e., it must be an InitialContextToken). In this trace, the mechToken contains raw NTLMSSP data, not an InitialContextToken containing NTLMSSP data. Based on the references I listed above, this behavior appears to be different than what is required by RFC 4178 and RFC 2743. See attached spnego_ntlmssp.cap, frame 6. Perhaps there is some confusion here because RFC 4178 section 3.2 mentions two separate calls to GSS_Accept_sec_context(). Initially, the entire GSS token (bytes 0x75-0xBE in this trace) is passed to GSS_Accept_sec_context(), as mentioned at the beginning of item (c), so it can be processed by the SPNEGO mechanism. Then, if the SPNEGO mechanism accepts the initiator's preferred mechanism, and the initiator included an optimistic mechToken (bytes 0x97-0xBE in this trace), the optimistic mechToken must be passed to GSS_Accept_sec_context() so it can be processed by the negotiated mechanism. This behavior is from the end of item (c), which I quote above. Based on my understanding, this second call to GSS_Accept_sec_context() is establishing a new inner context that uses the negotiated mechanism. Therefore this call to GSS_Accept_sec_context() is the also first call for this context, so it should receive an InitialContextToken. Admittedly, RFC 4178 could be a bit clearer in this regard. However, other available SPNEGO implementations appear to agree with my interpretation. For example, this appears to be how the MIT Kerberos implementation behaves: http://anonsvn.mit.edu/cgi-bin/viewcvs.cgi/trunk/src/lib/gssapi/spnego/spnego_mech.c?rev=19831view=markup They pass the received tokens to gss_init_sec_context()/ gss_accept_sec_context() with a separate inner context. As a result, the initial mechToken is always a GSS InitialContextToken. Expected: Even though we are not claiming compliance with RFC4178, the interpretation of '3.2. Negotiation Procedure' is a point of interest concerning how we embed the NTLM NEGOTIATE MESSAGE MechToken (Netmon 3.2 trace extract below, from the attached spnego_ntlmssp.cap, frame 6. The customer is requesting that we annotate this concerning that 'the Windows implementation does not accept well-formed GSS InitialContextTokens containing NTLM SSP'. - SecurityBlob: - GssApi: + ApplicationHeader: + ThisMech: SpnegoToken (1.3.6.1.5.5.2) - InnerContextToken: 0x1 - SpnegoToken: 0x1 + Tag0: - NegTokenInit: 0x1 + SequenceHeader: + Tag0: + MechTypes: + Tag2: + OctetStringHeader: - MechToken: NTLM NEGOTIATE MESSAGE + NLMP: NTLM NEGOTIATE MESSAGE Regards, Bill Wesse MCSE, MCTS / 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: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Monday
[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
I am curious about your thoughts concerning the below; I did a bit more looking
into the traces:
A note concerning 'spnego_ntlmssp.cap': the Network Monitor 3.1 parser
incorrectly marks the token as an 'InnerContextToken' instead of an
'InitialContextToken'.
From what I can see, spnego_ntlmssp.cap frame 6 conforms to RFC 2743.
Generic Security Service Application Program Interface Version 2, Update 1
http://www.ietf.org/rfc/rfc2743.txt?number=2743
3.1: Mechanism-Independent Token Format
1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
constructed form, definite length encoding follows.
2. Token length octets
3. 0x06 -- Tag for OBJECT IDENTIFIER
4. Object identifier length
5. Object identifier octets
The token tag is immediately followed by a mechanism-defined token
object.
MechType ::= OBJECT IDENTIFIER
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
}
==
spnego_ntlmssp.cap
Frame: Number = 6
- Smb: C; Session Setup Andx, NTLM NEGOTIATE MESSAGE
Command: Session Setup Andx 115(0x73)
+ NTStatus: 0x0, Facility = FACILITY_SYSTEM,
Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
+ SMBHeader: Command, TID: 0x, PID: 0xFEFF, UID: 0x, MID: 0x0040
- CSessionSetupAndXNTLMESS:
+ Capabilities: 0xA0D4
- SecurityBlob:
- GssApi:
- ApplicationHeader:
+ AsnId: Application Constructed Tag (0)
+ AsnLen: Length = 72, LengthOfLength = 0
+ ThisMech: SpnegoToken (1.3.6.1.5.5.2)
- InnerContextToken: 0x1 -- text should be 'InitialContextToken'
- SpnegoToken: 0x1
- Tag0: AsnId: Context Specific Constructed Tag (0)
- NegTokenInit: 0x1
- SequenceHeader: AsnId: Sequence and SequenceOf types (Universal 16)
- Tag0: AsnId: Context Specific Constructed Tag (0)
- MechTypes:
+ SequenceHeader:
+ MechType: NLMP (1.3.6.1.4.1.311.2.2.10)
- Tag2: AsnId: Context Specific Constructed Tag (2)
- OctetStringHeader: AsnId: OctetString type (Universal 4)
- MechToken: NTLM NEGOTIATE MESSAGE
- NLMP: NTLM NEGOTIATE MESSAGE
Signature: NTLMSSP
MessageType: Negotiate Message (0x0001)
- NegotiateFlags: 0xE2088297 (NTLM v2128-bit encryption, Always Sign)
+ WorkstationDomainHeader: Length: 0, Offset: 0
+ WorkstationNameHeader: Length: 0, Offset: 0
+ Version: Windows 5.1 Build 10250 NLMPv15
Regards,
Bill Wesse
MCSE, MCTS / 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, October 29, 2008 3:48 PM
To: 'Adam Simpkins'
Cc: '[EMAIL PROTECTED]'
Subject: RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in
GSS-API/SPNEGO
Thanks! I will proceed with that info.
Regards,
Bill Wesse
MCSE, MCTS / 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: Adam Simpkins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2008 3:09 PM
To: Bill Wesse
Cc: '[EMAIL PROTECTED]'
Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in
GSS-API/SPNEGO
On Wed, Oct 29, 2008 at 09:37:05AM -0700, Bill Wesse wrote:
Adam, thank you very much for your persistence.
I apologize for responding against the two issues with the same
answer. In order to make sure I don't commit another mix-up, I have
superseded SRX080803600053 with SRX081029600208.
I did a careful backtrack on the question/response history, and
noticed something that surprised and disappointed me: in the below
partial RESPONSE text, we are essentially claiming that our own XP
Client is sending an invalid NTLM SSP token.
I think we confused how gss_ntlmssp.cap was generated (XP - 2003)
with how raw_ntlmssp.cap was generated (which, as you noted, had the
security blob stripped).
No, you had this part correct. raw_ntlmssp.cap contains an unmodified
SESSION_SETUP_ANDX request generated by an XP client. (However, in
order to generate it, I stripped the security blob from the server's
NEGOTIATE response. If the server includes a security blob in the
NEGOTIATE response, XP clients always use SPNEGO. With no security
blob, they use raw NTLM SSP without SPNEGO or GSS. In the past, I
have seen some servers in the field generate NEGOTIATE responses with
no security blob, but I don't recall what OS or version they were
running.)
The gss_ntlmssp.cap traces was taken using a custom client configured
to always generate a GSS InitialContextToken for the very first
security blob
[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
Adam, thank you very much for your persistence. I apologize for responding against the two issues with the same answer. In order to make sure I don't commit another mix-up, I have superseded SRX080803600053 with SRX081029600208. I did a careful backtrack on the question/response history, and noticed something that surprised and disappointed me: in the below partial RESPONSE text, we are essentially claiming that our own XP Client is sending an invalid NTLM SSP token. I think we confused how gss_ntlmssp.cap was generated (XP - 2003) with how raw_ntlmssp.cap was generated (which, as you noted, had the security blob stripped). I expect to file a new bug concerning this later today, after reviewing the latest internal builds of the documents. RESPONSE: ... The RAW NTLM SSP token in your sniff gss_ntlmssp.cap contains the GSS InitialContextToken syntax using the NTLM SSP OID and this is not a valid NTLM SSP token. ... Network traces: Windows XP SP3 and a server running Windows Server 2003 SP2 (Enterprise Edition). GSS InitialContextTokens with SPNEGO: spnego_ntlmssp.cap frames 6, 7, 8 9 GSS InitialContextTokens without SPNEGO: gss_ntlmssp.cap frames 7 8 Regards, Bill Wesse MCSE, MCTS / 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: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 2:56 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO On Tue, Oct 28, 2008 at 02:45:19AM -0700, Bill Wesse wrote: Good morning Mr. Simpkins. I have attached '[MS-SPNG]_Changes.pdf', which shows the changes we have made to [MS-SPNG], as well as the responses to your comments and questions (below). Please let me know if this answers your questions satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. Thanks for the reply, I still believe the last two items below need addressing: COMMENT: NegTokenInit's MechToken contains an NTLMSSP blob - not per RFC. RESPONSE: This is explained in [MS-SPNG] 3.2.5.2 of the Windows Behavior notes. 3.2.5.2 Universal Receiver 8 This behavior is present on Windows 2000, Windows XP, Windows Server 2003, and Windows Vista. For backward compatibility and historical reasons, a Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the universal receiver behavior. Yes, this part of the case can be resolved. COMMENT: mechType identification should be more clearly referenced in main body of the document. RESPONSE: Please see the attached document '[MS-SPNG]_Changes.pdf'. COMMENT: OID 1.2.840.113554.1.2.2 is ALWAYS included in the mechToken/responseToken. RESPONSE: Please see the attached document '[MS-SPNG]_Changes.pdf'. Thanks, that looks good. COMMENT: Another related point that should probably be documented is that Windows servers do not seem to accept well-formed GSS InitialContextTokens containing NTLMSSP RESPONSE: The SPNEGO universal responder behavior says that the SPNEGO server accepts RAW NTLM and RAW Kerberos tokens. The RAW NTLM SSP token in your sniff contains the GSS InitialContextToken syntax using the NTLM SSP OID and this is not a valid NTLM SSP token. In section 2.2 of the MS NTLM document (MS-NLMP) we can see that NTLMSSP does not use the GSS InitialContextToken syntax and all the NTLM token messages are in one of the NEGOTIATE_MESSAGE (2.2.1.1), CHALLENGE_MESSAGE (2.2.1.2) or AUTHENTICATE_MESSAGE (2.2.1.3) syntax. The failure to accept InitialContextToken wrapped NTLM tokens is not considered as a behavior of SPNEGO but the behavior of NTLM SSP. In this case, SPNEGO only accepts valid NTLM tokens where your NTLM tokens in the sniff with the GSS InitialContextToken syntax is considered invalid by the NTLM SSP. Do we really have to go over this point again? We discussed this at length in previous emails. [MS-SMB] states that when CAP_EXTENDED_SECURITY is set, the SecurityBlob contained in the SESSION_SETUP_ANDX request is a GSS token. See [MS-SMB] 3.3.5.3 and 3.2.5.3. RFC 2743 section 3.1 defines the format for the initial token of a GSS context establishment sequence (i.e., a GSS InitialContextToken, containing the mechanism specific token as the innerContextToken). With NTLM SSP chosen as the GSS mechanism, this would clearly mean that the very first token exchanged should be a GSS InitialContextToken containing a NTLM SSP token. 5.) QUESTION: This issue is closely related to the second remaining issue, which is that Windows server's don't accept NTLM messages properly embedded
[cifs-protocol] RE: Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages
Thank you again Andrew. I am proceeding with an enumeration of the linkage list, for submission to document development. Regards, Bill Wesse MCSE, MCTS / 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: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 8:02 AM To: Bill Wesse Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages On Fri, 2008-10-17 at 03:38 -0700, Bill Wesse wrote: Thanks Andrew - especially for the corrections. Just to clarify, the document was never meant to be standalone; It is a very useful thing standalone, or alongside the main document, because it is organised differently, and even just that makes it easier to work with (sometimes it is great to have two different ways to approach the info). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages
Thanks Andrew - especially for the corrections. Just to clarify, the document was never meant to be standalone; it is basically a set of notes I took during running down parameter storage. I do have more work to do before submitting the contained information as a change proposal for [MS-NRPC]. Of course, I do have more work to do before that, and I will keep you advised as I progress. Regards, Bill Wesse MCSE, MCTS / 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: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2008 1:12 AM To: Bill Wesse Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages On Wed, 2008-10-15 at 06:40 -0700, Bill Wesse wrote: Good morning Andrew. For your review, I have attached a working document that details usage and Active Directory storage of several select parameters used by [MS-NRPC] operations. The parameter notes in the document are not complete, and several require additional research. Additionally, the document is organized around operation parameters by name, not by operation. This is for the purpose of brevity. I though it would be unproductive to insert comments into sections of the original [MS-NRPC] document as examples - which is what this doc is, example text. I would deeply appreciate your feedback concerning the quality of, and whether or not this is the sort of information you are looking for concerning the backing store information for the [MS-NRPC] operations parameters. This is looking good, and seems quite a reasonable way to approach the problem. A few errors (just because I'm picky :-): 1.1 You give a lot of detail about accountName, except the actual attribute. 1.3 DomainName is not stored in the DC attribute - this is just the first component of the domain name. The example objects are not the most useful thing - if they are just un-annotated LDIF pastes. (I can usually find them by a simple search on my test DC, but probably do help the hypothetical target of a independent developer not performing network analysis). I do look forward to the completed document. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: (more) Backing store for Trusted domain object creation time and flags
Good morning Andrew. Thank you for raising the questions! I have created the
following case for you; one of me team mates or myself will take ownership of
the case shortly and will contact you.
SRX081013600072 [MS-LSAD] 2.2.69 LSA_FOREST_TRUST_RECORD LDAP
Regards,
Bill Wesse
MCSE / 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: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Monday, October 13, 2008 5:00 AM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: (more) Backing store for Trusted domain object creation time and flags
In 2.2.69 LSA_FOREST_TRUST_RECORD it states:
typedef struct _LSA_FOREST_TRUST_RECORD {
unsigned long Flags;
LSA_FOREST_TRUST_RECORD_TYPE ForestTrustType;
LARGE_INTEGER Time;
Time: The date and time when this entry was created. It is a 64-bit value that
represents the
number of 100-nanosecond intervals since January 1, 1601, UTC.
I presume this is just the whenCreated attribute on this record, but no link is
made.
However, I'm more puzzled by the 'Flags' - where does this come from (in terms
of LDAP attributes)?
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status: SRX080811600226 ([MS-NRPC] 2.2.1.3.12 Trust Account Details) superceded by SRX081013600536: [MS-NRPC] operation backing store linkages
Good morning Andrew. Since the original comments and questions you raised in
SRX080811600226 about backup store linkages did not result in any material
updates to the documents, I have created SRX081013600536 for continuance (and
have closed SRX080811600226).
I am currently beginning a study of the MS-NRPC operation parameters, in order
to compile a cross reference list, which I will submit to development as a
well-annotated table, with back references to the operations sections. I am not
sure at this time which of the columns should be the independent column
(parameter or AD attribute). I would appreciate your input on this point, as
you undoubtedly have a better insight than I into document usage.
Sorry it took me this long to get to this point.
==
Question:
The MS-NRPC document does not specify the linkage to the backing store
for any of it's operations.
For example, the NetServerAuthenticate3 query talks only about client
computer accounts, but in 2.2.1.3.12 NETLOGON_SECURE_CHANNEL_TYPE,
interdomain trust accounts are described.
==
Response:
Some of this data is already described in the document. Section 3.1.1.
Abstract Data Model has entry for SharedSecret along with description
of where the data is stored.
Only as an obscure 'microsoft behaviour note'. This is not a minor detail of
protocol behaviour, and deserves to be referenced in a major table matching
protocol elements with their underlying backing store.
This table is what I want to see across all the protocols - as the
double-mapping between protocol structure elements, abstract data modals and
the occasional Microsoft behaviour notes detailing the backing store is a big
problem.
Similarly, because it is do dispersed, it is not possible for you to show
completeness in the mapping either.
Computer accounts are stored in AD under the CN=Computers and trusts
are stored in Trusted Domain Objects described in section 7.1.6.2 of
[MS-ADTS].
Please refer to our response (currently incomplete) concerning trust
backing store information against the other case we are working on for
you: SRX080731600024 [MS-ADTS] 7.1.6 Relationship between trusted
domain objects
==
Question:
It makes sense that these both refer to computer and domain trust
accounts found under cn=users, but this is not specified, nor are the
attributes used specified.
Similarly, the NetrSetPassword2 call sets a trust account password,
but the operation of this call - what LDAP/DRS visible attribute it
changes - are not specified.
==
Response:
This data is already described in the document. Section 3.1.1.
Abstract Data Model has entry for SharedSecret along with description
of where the data is stored.
Except changing a password does far more than simply change the value of
unicodePwd. This is the problem with the proxy via the abstract data modal -
it misses details.
==
Question:
Please start with these, but to also note that, the 3.5.4.5.2
NetrDatabaseSync{,2} calls need the same level of specification.
These are just examples - like in my request regarding LSA, can you
please clarify for the whole document which protocol buffers line up
with which objects and attributes in the underlying database.
==
Response:
Since this is RPC based protocol, there are no buffers to be
described. The only exception is the Netlogon SSP documentation, but
those are covered by the above two responses.
Please could you re-read and re-answer the question in a more broad light,
taking buffers as a synonym for perhaps RPC protocol structure elements? Thanks
Regards,
Bill Wesse
MCSE, MCTS / 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
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
You are, as always, completely welcome! Regards, Bill Wesse MCSE / 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 We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted -Original Message- From: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2008 12:14 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO On Wed, Oct 08, 2008 at 07:55:52AM -0700, Bill Wesse wrote: My pleasure! Here is copy of tentative text changes to the [MS-SPNG] document (these are waiting for internal approval - I will advise you as soon as the text is finalized): Thanks. The new text looks good. -- Adam Simpkins [EMAIL PROTECTED] ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
My pleasure!
Here is copy of tentative text changes to the [MS-SPNG] document (these are
waiting for internal approval - I will advise you as soon as the text is
finalized):
==
OID 1.2.840.113554.1.2.2 is ALWAYS included in the mechToken/responseToken.
--
Original text:
5 Section 3.1.5.2: Windows versions offer and accept two distinct OIDs as
identifiers for the Kerberos authentication mechanism. The SPNEGO
extensions consider both OIDs as equivalent and make no distinction
between them.
Windows 2000 incorrectly encoded the OID for the Kerberos protocol. Rather
than the OID { iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the
values at 16 bits. Therefore, the OID became { iso(1) member-body(2)
United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }. 48018 is
not a known member under that OID branch; this is an error.
Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
do not truncate the value, and they correctly offer and receive
1.2.840.113554.1.2.2. For compatibility reasons, the erroneous value
(1.2.840.48018.1.2.2) is still offered and accepted by systems that run
Windows 2000. The presence of this value can be used to determine that the
peer is a Windows 2000 implementation.
New text:
5 Section 3.1.5.2: Windows versions offer and accept two distinct OIDs as
identifiers for the Kerberos authentication mechanism. The SPNEGO
extensions consider both OIDs as equivalent and make no distinction
between them.
Windows 2000 incorrectly encoded the OID for the Kerberos protocol. Rather
than the OID { iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the
values at 16 bits. Therefore, the OID became { iso(1) member-body(2)
United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }. 48018 is
not a known member under that OID branch; this is an error. The singular
presence of this incorrect OID (1.2.840.48018.1.2.2) can be used to
determine that the peer is a Windows 2000 implementation.
Windows XP and later do not truncate the OID, and they correctly offer
and receive 1.2.840.113554.1.2.2. For compatibility reasons, on Windows XP
and later, the erroneous value (1.2.840.48018.1.2.2) is sent in addition
to the correct value (1.2.840.113554.1.2.2) Both values are considered
equivalent and Windows makes no distinction between the two.
The mechToken and responseToken always contain the standard OID
(1.2.840.113554.1.2.2) within the thisMech field, even when the
supportedMech chosen by SPNEGO is (1.2.840.48018.1.2.2). Windows Kerberos
servers do not accept the truncated OID in the thisMech field.
Regards,
Bill Wesse
MCSE / 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
We're Hiring
http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted
-Original Message-
From: Adam Simpkins [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2008 10:08 PM
To: Bill Wesse
Cc: '[EMAIL PROTECTED]'
Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in
GSS-API/SPNEGO
On Fri, Oct 03, 2008 at 07:18:05AM -0700, Bill Wesse wrote:
Good morning again! Our documentation development team advises me the
following change will be implemented in a future posting of [MS-SMB]:
[MS-SMB]: Server Message Block (SMB) Protocol Specification
Section 3.2.4.2.3 User Authentication (Extended Security subtopic)
Current Text:
In either case, it initializes the GSS authentication protocol with the
MutualAuth and Delegate options, which are specified in [MS-KILE] section
3.2.1.1.173
Request to update with:
In either case, it initializes the GSS authentication protocol with the
MutualAuth and Delegate options, which are specified in [MS-KILE] section
3.2.1.1.173 See also [MS-SPNG] section 3.2.5.2.
Okay. Thanks for the update.
--
Adam Simpkins
[EMAIL PROTECTED]
___
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Response: SRX080909600334: [MS-APDS] Backing store and policy application information
Good morning Andrew. I have completed my preliminary investigation concerning your questions about password policy, validation and concrete backing store for user and trust account attributes. The information is presented in detail in the attached document (PasswordPolicyAndValidation.pdf, summary below). What would you like the document to read as? I have listed several suppositions where I think references may be helpful. The following document sections should have cross references to: [MS-SAMR] 5.2 Index of Security Parameters a. [MS-ADTS] 3.1.1.3.1.5 Password Modify Operations b. [MS-APDS] 3.1.5.1 NTLM Interactive Logon c. [MS-NRPC] 3.1.1 Abstract Data Model (SharedSecret:) Summary: 1. The document contains a detailed table of the member derivations for the NETLOGON_VALIDATION_SAM_INFO4 structure shown in [MS-NRPC] 2.2.1.4.13. 2. The document also contains a table that combines information concerning password policy checks, derived from the list below. The table includes additional document cross references ([MS-SAMR], [MS-KILE], etc.). [MS-SAMR] 2.2.1.13 UF_FLAG Codes 3.1.1.8.10 userAccountControl 3.1.5.14.2 userAccountControl Mapping Table 3. The document also provides references to information concerning password validation attributes, as discussed in various sections in [MS-ADTS], [MS-NRPC] and [MS-SAMR]. The best description of vailidation with respect to the dbcsPwd and unicodePwd are in the following references: [MS-SAMR] 3.1.5.10.1 SamrChangePasswordUser (Opnum 38) 3.1.5.13.8 SamrValidatePassword == Request: I have previously asked for information to be added to MS-NRPC to detail the currently abstract backing store for user and trust accounts. However, it happens that the normal SamLogon processing is mostly described in [MS-APDS]. What I'm looking for is a specific description of what attributes (unicodePwd, dbcsPwd) are used for validating the password, what attributes (pwdLastSet, userAccountControl etc) are used (and how they are used) to check policy and then what attributes are used to construct the NETLOGON_VALIDATION_SAM_INFO4. I need this because I must construct the same reply as a Microsoft DC that I might share a domain using DRS replication with. The current text in [MS-APDS] 3.1.5.1 is: The domain controller MUST compare the local copy of the password to the one sent in the request. If there is a successful match, the domain controller MUST return data with ValidationInformation containing either a reference to NETLOGON_VALIDATION_SAM_INFO4 ([MS-NRPC] section 3.5.4.4.1), if the ValidationLevel in the request is NetlogonValidationSamInfo4 or a reference to NETLOGON_VALIDATION_SAM_INFO2 ([MS-NRPC] section 3.5.4.4.1), if the ValidationLevel in the request is NetlogonValidationSamInfo2). If there is not a match, the DC MUST return the failure error code STATUS_WRONG_PASSWORD (section 2.2) with no response data.15 Regards, Bill Wesse MCSE / 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: New case: SRX080910600015: [MS-ADA3]: 2.44 Elaborate on objectSid definition
Good morning Andrew. Per your inquiry concerning elaboration on the objectSid definition, I am sending you copy of an update to the documentation as shown below (the second paragraph is new content). Please let me know if this answers your question satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation. == [MS-ADA3]: Active Directory Schema Attributes N-Z 2.44 Attribute objectSid This attribute specifies a binary value that specifies the security identifier (SID) of the user. The SID is a unique value used to identify the user as a security principal. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. Because this is an attribute of String(SID) syntax, an application writing to this attribute via the LDAP protocol can specify a value for this attribute as a valid SDDL SID string, as specified in [MS-ADTS] section 3.1.1.3.1.2.5. The directory service will convert that value to its binary value equivalent. cn: Object-Sid ldapDisplayName: objectSid attributeId: 1.2.840.113556.1.4.146 attributeSyntax: 2.5.5.17 omSyntax: 4 isSingleValued: TRUE schemaIdGuid: bf9679e8-0de6-11d0-a285-00aa003049e2 systemOnly: TRUE searchFlags: fPRESERVEONDELETE | fATTINDEX rangeLower: 0 rangeUpper: 28 attributeSecurityGuid: 59ba2f42-79a2-11d0-9020-00c04fc2d3cf mapiID: 32807 isMemberOfPartialAttributeSet: TRUE systemFlags: FLAG_SCHEMA_BASE_OBJECT | FLAG_ATTR_REQ_PARTIAL_SET_MEMBER schemaFlagsEx: FLAG_ATTR_IS_CRITICAL Version-Specific Behavior: Implemented on Windows 2000 Server, Windows Server 2003, Windows Server 2003 R2, and Windows Server 2008. In Windows 2000 Server, the following attributes are defined differently: systemOnly: FALSE The schemaFlagsEx attribute was added to this attribute definition in Windows Server 2008. == Regards, Bill Wesse MCSE / 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: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 8:30 AM To: Bill Wesse Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: New case: SRX080910600015: [MS-ADA3]: 2.44 Elaborate on objectSid definition On Wed, 2008-09-10 at 03:34 -0700, Bill Wesse wrote: Good morning Andrew. I have created the new case as noted in the Subject line. I expect you will be happy to know that we are initiating a strong recommendation that the objectSid definition in [MS-ADA3] be modified as shown below. Thank you for your persistence on this topic. No worries. I will keep you advised of progress! Change: 2.44 Attribute objectSid This attribute specifies a binary value that specifies the security identifier (SID) of the user. The SID is a unique value used to identify the user as a security principal. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. To: 2.44 Attribute objectSid This attribute specifies a variable-length byte array value that specifies the security identifier (SID) of the user. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. It also may be represented as a UTF-8 string that is a valid SDDL SID string beginning with S- (see [MS-DTYP] sections 2.4.2 and 2.5.1, and [MS-ADTS] 3.1.1.3.1.2.5). The SID is a unique value used to identify the user as a security principal. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. That looks good. Let me know how you go - I had understood from the call that we were at a stalemate, so I'm particularly glad to see this (potentially) moving forward. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
Good morning! I indeed should have noted the change was made to [MS-SPNG] instead of [MS-NLMP] (thanks for catching that). I have just submitted your comments (shown immediately below) as a change request against [MS-SPNG]. ...the phrase that are not embedded in [RFC4178] SPNEGO messages should be changed to that are not embedded in [RFC2743] GSS-API InitialContextTokens... I have also submitted another change request to add a reference from [MS-SMB] section 3.2.4.2.3 to [MS-SPNG] Section 3.2.5.2 Universal Receiver to the 'Extended Security' subtopic. This was actually in the original change request (which was against [MS-SMB], but the [MS-SPNG] text was the only resulting change). Sorry we missed the original target. Regards, Bill Wesse MCSE / 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: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2008 4:48 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' Subject: Re: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO On Thu, Sep 18, 2008 at 06:29:00AM -0700, Bill Wesse wrote: Good afternoon Mr. Simpkins. We have completed our investigations concerning your request for correction assistance regarding NTLM authentication using SPNEGO (in [MS-NLMP]), and have provided the document changes shown below. These changes will be available in a future document refresh. Please note that your other comments (shown in 'Remaining Issues' below are still under investigation. I will keep you updated as developments occur. == Original Comment: When NTLM authentication is negotiated over SPNEGO, Windows clients do not properly wrap the initial NTLM token inside a GSS-API InitialContextToken (described in RFC 2743 section 3.1). [MS-NLMP] Document Change: Did you mean [MS-SPNG] instead of [MS-NLMP] here? MS-NLMP section 3.2.5.2 doesn't seem relevant. # Section 3.2.5.2: This behavior is present on Windows Vista, Windows Server 2003, Windows XP, and Windows 2000. For backward compatibility and historical reasons, the Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the Universal Receiver behavior. This doesn't seem like much of a change to me. The wording is slightly different but the meaning appears to be the same as the original text. As I've mentioned in several previous emails, the windows extension is that it accepts raw NTLM messages that are not embedded in [RFC2743] GSS-API InitialContextTokens. At the very least, the phrase that are not embedded in [RFC4178] SPNEGO messages should be changed to that are not embedded in [RFC2743] GSS-API InitialContextTokens. From the very first email I sent regarding this issue: On Fri, Aug 01, 2008 at 05:12:13PM -0700, Adam Simpkins wrote: The one thing I did find that could potentially be considered to explain this behavior is in item 8 in Appendix A of MS-SPNG: For backward compatibility and historical reasons, a Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the universal receiver behavior. I find this passage slightly strange--for Kerberos, this seems to be standard behavior, and not a Windows extension. Any conforming GSS-API implementation that supports both SPNEGO and Kerberos should accept InitialContextTokens containing either SPNEGO or Kerberos tokens. Therefore, the Windows behavior could perhaps best be described not by the statement above, but by the Windows GSS-API implementation accepts as the first token a raw NTLM message that is not embedded in an [RFC2743] InitialContextToken. This wording could also be considered to explain the fact that Windows servers accept the a raw NTLM token in the SPNEGO mechToken. If this text is changed to properly indicate that Windows servers accept NTLM messages not embedded in GSS-API InitialContextTokens, it will probably also be necessary to clarify that this occurs both with and without SPNEGO. When SPNEGO is not in use, Windows servers accept a raw NTLM message instead of the GSS-API InitialContextToken (see the trace raw_ntlmssp.cap frame 7). When SPNEGO is in use, Windows servers accept a raw NTLM message in the SPNEGO mechToken/respToken field, instead of a GSS InitialContextToken (see trace spnego_raw_ntlmssp.cap frame 6). This issue is closely related to the second remaining issue, which
[cifs-protocol] RE: SRX080909600334: [MS-APDS] Backing store and policy application information
Good morning again Andrew. I am near to completion with my investigation, and expect to provide you with the results for your review on Monday. Once we are at the point of having the necessary information, I will file appropriate documentation change requests. Regards, Bill Wesse MCSE / 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 We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted From: Bill Wesse Sent: Tuesday, September 09, 2008 12:37 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: SRX080909600334: [MS-APDS] Backing store and policy application information Good morning Andrew! I have just taken ownership of this case from my colleague, Edward, since it is closely related to several other cases I am working for you. I expect to begin work on this tomorrow, and will advise you of progress as soon as possible. == Question == I have previously asked for information to be added to MS-NRPC to detail the currently abstract backing store for user and trust accounts. However, it happens that the normal SamLogon processing is mostly described in MS-APDS (for some reason). What I'm looking for is a specific description of what attributes (unicodePwd, dbcsPwd) are used for validating the password, what attributes (pwdLastSet, userAccountControl etc) are used (and how they are used) to check policy and then what attributes are used to construct the NETLOGON_VALIDATION_SAM_INFO4. I need this because I must construct the same reply as a Microsoft DC that I might share a domain using DRS replication with. The current text in 3.1.5.1 is: The domain controller MUST compare the local copy of the password to the one sent in the request. If there is a successful match, the domain controller MUST return data with ValidationInformation containing either a reference to NETLOGON_VALIDATION_SAM_INFO4 ([MS-NRPC] section 3.5.4.4.1), if the ValidationLevel in the request is NetlogonValidationSamInfo4 or a reference to NETLOGON_VALIDATION_SAM_INFO2 ([MS-NRPC] section 3.5.4.4.1), if the ValidationLevel in the request is NetlogonValidationSamInfo2). If there is not a match, the DC MUST return the failure error code STATUS_WRONG_PASSWORD (section 2.2) with no response data.15 (Just to put this into context, this needs a long-term answer and doc change, not a 'hot fix'). == Regards, Bill Wesse MCSE / 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 We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO
Good morning once again Adam. I am sending this, as I have not received your response to my email of Sept 10 (shown below). Please note the information provided below lists remaining issues, which our document developers are still working on. I will update you as information develops. Regards, Bill Wesse MCSE / 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, September 10, 2008 7:14 AM To: 'Adam Simpkins' Cc: '[EMAIL PROTECTED]' Subject: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO Good afternoon Mr. Simpkins. We have completed our investigations concerning your request for correction assistance regarding NTLM authentication using SPNEGO (in [MS-NLMP]), and have provided the document changes shown below. These changes will be available in a future document refresh. Please note that your other comments (shown in 'Remaining Issues' below are still under investigation. I will keep you updated as developments occur. == Original Comment: When NTLM authentication is negotiated over SPNEGO, Windows clients do not properly wrap the initial NTLM token inside a GSS-API InitialContextToken (described in RFC 2743 section 3.1). [MS-NLMP] Document Change: # Section 3.2.5.2: This behavior is present on Windows Vista, Windows Server 2003, Windows XP, and Windows 2000. For backward compatibility and historical reasons, the Windows implementation of SPNEGO has the following behavior: it accepts raw Kerberos messages that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO messages. This behavior is known as the Universal Receiver behavior. == Remaining Issues: [MS-SPNG] Inside the actual note 5 in Appendix A, it would be nice to also mention that the inner mechToken/responseToken always contains the standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2. Windows servers do not accept the truncated OID in the thisMech field. Another related point that should probably be documented is that Windows servers do not seem to accept well-formed GSS InitialContextTokens containing NTLMSSP. I have attached a trace of that, too (gss_ntlmssp.cap frame 7). (The server is the same Windows Server 2003 system as in the other traces.) Regards, Bill Wesse MCSE / 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] New case: SRX080910600015: [MS-ADA3]: 2.44 Elaborate on objectSid definition
Good morning Andrew. I have created the new case as noted in the Subject line. I expect you will be happy to know that we are initiating a strong recommendation that the objectSid definition in [MS-ADA3] be modified as shown below. Thank you for your persistence on this topic. I will keep you advised of progress! Change: 2.44 Attribute objectSid This attribute specifies a binary value that specifies the security identifier (SID) of the user. The SID is a unique value used to identify the user as a security principal. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. To: 2.44 Attribute objectSid This attribute specifies a variable-length byte array value that specifies the security identifier (SID) of the user. For more information on the SID data type, refer to [MS-DTYP] section 2.4.2. It also may be represented as a UTF-8 string that is a valid SDDL SID string beginning with S- (see [MS-DTYP] sections 2.4.2 and 2.5.1, and [MS-ADTS] 3.1.1.3.1.2.5). The SID is a unique value used to identify the user as a security principal. SID usage is also discussed in [MS-ADTS], in particular in section 3.1.1.1.3. Regards, Bill Wesse MCSE / 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 ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
