[cifs-protocol] Scope of a File.LeaseKey on the client
Hi DocHelp, is it correct that the LeaseKey on a file is shared between different user contexts? From 3.2.4.3 Application Requests Opening a File: [...] If the client implements the SMB 2.1 or SMB 3.0 dialect and Connection.SupportsFileLeasing is TRUE, the client MUST search the GlobalFileTable for an entry matching one of the following: - The application-supplied PathName if TreeConnect.IsDfsShare is TRUE. - The concatenation of Connection.ServerName, TreeConnect.ShareName, and the application-supplied PathName, joined with pathname separators (example: server\share\path), if TreeConnect.IsDfsShare is FALSE. If an entry is not found, a new File entry MUST be created and added to the GlobalFileTable and a File.LeaseKey, as specified in section 3.2.1.5, MUST be assigned to the entry. File.OpenTable MUST be initialized to an empty table and File.LeaseState MUST be initialized to SMB2_LEASE_NONE. [...] If the client accesses a file through multiple paths, such as using different server names or share names or parent directory names, it will create multiple File elements, and therefore multiple File.LeaseKeys for the same remote file. This loses the performance benefits of sharing cache state across all Opens of the same file, and may cause additional lease breaks to be generated, as actions by a client through one path will affect caching by that client through other paths. However, the impact is a matter of performance; cache correctness is preserved. [...] It seems that the LeaseKey is purely tight to the full path to the file from the client perspective. I guess on a terminal server where multiple users access the same path on the server, the LeaseKey is shared between them, is that correct? If this is true, then this implies that each user sees the same content in a file, which might not be true. E.g. in Samba we allow shares to expose different FSA level directories based on user account. The typical example is the homes share which exposes the unix home directory of the specific user. I fear that we have to disable such powerful features if we want to take advantage of leases, otherwise the client would treat \\sambaserver\homes\commonfile.doc of user1 and \\sambaserver\homes\commonfile.doc of user2 as the same file. I assume user1 and user2 should share the client_guid and lease_key, which means data corruption and/or security problems are very likely, if the server grants leases in this case. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 112091915263549] clarification for application instance ID
Hi Edgar, The case number 112091915263549 has been created to track this inquiry. I will assist you in resolving this issue. In the SMB2_CREATE_APP_INSTANCE_ID Create Context: DataOffset: 36 (0x24) should be DataOffset: 32 (0x20) and no padding is required. You have 4 extra bytes of zeros padding after the SMB2_CREATE_APP_INSTANCE_ID context name. 00 00 00 00 10 00 10 00 00 00 24 00 14 00 00 00 45 BC A6 6A EF A7 F7 4A 90 08 FA 46 2E 14 4D 74 00 00 00 00 14 00 00 00 67 5F D4 1E 7C E4 55 42 88 1D E6 9F C3 9E 0A F6 Here is an example of working create context: 00 00 00 00 10 00 10 00 00 00 20 00 14 00 00 00 45 BC A6 6A EF A7 F7 4A 90 08 FA 46 2E 14 4D 74 14 00 00 00 65 E3 26 E0 E7 03 50 44 9B B9 E5 A5 45 FF C0 4C Thanks, we had a bug on out side, which we have fixed in master now. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 112080853508014] SMB3 channel sequence questions. When is Open.OutstandingPreRequestCount supposed to be decremented or reset
Hi Edgar, Regarding “when should the server decrement OutstandingPreRequestCount or OutstandingRequestCount”, the following logic will be reflected in a future release of the MS-SMB2 document. This occurs during post processing check of the ChannelSequence. 3.3.4.1 Sending Any Outgoing Message Unless specifically noted in a subsequent section, the following logic MUST be applied to any response message being sent from the server to the client. • For every outgoing message, the server MUST calculate the total number of bytes in the message and update the values of ServerStatistics.sts0_bytessent_low and ServerStatistics.sts0_bytessent_high. • For a command request that includes a FileId, if Connection.Dialect is “3.000” and ChannelSequence in the request is less than Open.ChannelSequence, the server MUST decrement Open.OutstandingPreRequestCount by 1. If ChannelSequence in the request is not less than Open.ChannelSequence, the server MUST decrement Open.OutstandingRequestCount by 1. Thanks! metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB3 encryption over multiple requests
Hi, I just found out that windows2012 RC sends multiple compound requests within just one encrypted SMB2_TRANSFORM message. From reading [MS-SMB2] version 37.0 I had the impression that each request would be encrypted on its own, similar to how signing works. Can the other receiver side rely on the fact that all messages within a SMB2_TRANSFORM message belong to the same session as the session (referenced by the session id in the SMB2_TRANSFORM header) used for the encryption? What will happen if a client send unrelated compound requests? What about async responses with STATUS_PENDING, are they also encrypted? How does it work, when the last request in a compound chain goes async? Are Oplock/Lease Break Notifications encrypted? Can there be more than one SMB2_TRANSFORM message within a transport layer message? metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB3 channel sequence
Hi DocHelp, I have some questions regarding the channel sequence verification of SMB 3.00. - When is Open.OutstandingPreRequestCount supposed to be decremented or reset? - What happens on an 16-bit overflow? From the documentation it looks like, the server would always reject write/ioctl/setinfo with STATUS_FILE_NOT_AVAILABLE once the channel sequence wrapped. - As the client maintains the channel sequence on the session, while the server maintains it on the open, it seems not to be unlikely that the values get out of sync. (Assuming there's a way to handle the general 16-bit overflow) It could happen that the client opened a file and doesn't use the handle for a long time (while the 16-bit value got an overflow on the client). This would mean that the server can know if a channel sequence is older or newer than the last one. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] When will clients/applications do a smb2 session reauth
Hi, with SMB 2.1 (and higher) it's possible to do a session re-authentication without getting a STATUS_NETWORK_SESSION_EXPIRED. With SMB 2.0 STATUS_REQUEST_NOT_ACCEPTED is returned. In what situations do clients do a (pro active) reauthentication without getting STATUS_NETWORK_SESSION_EXPIRED from the server? 3.2.4.2.3.1 Application Requests Reauthenticating a User is the related section in [MS-SMB2]. What layers in the client use this feature? How can I trigger this? Is the reauthentication only used with the same user account or also to switch a session to a different user (which is possible)? BTW: is there a reason why doch...@winse.microsoft.com doesn't work anymore? metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] When will clients/applications do a smb2 session reauth
Hi, with SMB 2.1 (and higher) it's possible to do a session re-authentication without getting a STATUS_NETWORK_SESSION_EXPIRED. With SMB 2.0 STATUS_REQUEST_NOT_ACCEPTED is returned. In what situations do clients do a (pro active) reauthentication without getting STATUS_NETWORK_SESSION_EXPIRED from the server? 3.2.4.2.3.1 Application Requests Reauthenticating a User is the related section in [MS-SMB2]. What layers in the client use this feature? How can I trigger this? Is the reauthentication only used with the same user account or also to switch a session to a different user (which is possible)? metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB2: ioctl max size
Hi dochelp, I wondering if there are any size limitations based on MaxTransactSize, MaxReadSize and/or MaxWriteSize in SMB2 IOCTL? I can't find anything related in the docs, but I guess there is a size limitation too. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111080856926389] Nameconflict with ss vs. ß
Hi Obaid, Please let me know if my reply resolved your problem. Yes, sorry for the late response. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Nameconflict with ss vs. ß
Hi, I found that objects with ss and ß in the DN conflict with each other. e.g.: If I create CN=User_ß,OU=test,DC=example,DC=com on DC1 and CN=User_ss,OU=test,DC=example,DC=com on DC2, CN=User_ss,OU=test,DC=example,DC=com gets renamed to CN=User_ß\x0aCNF:ee47b3a2-c1c5-11e0-a500-1b2ff2ce35e2,OU=test,DC=example,DC=com Based on [MS-DRDR] 4.1.10.6.12 MakeConflictDN. Can you please explain/document why 'ss' and 'ß' are handled as the same? As MS-DRDR is marked as hostoric, I'm wondering where the MakeConflictDN section is documented? It's not in [MS-DRDM] - v20110504. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [MS-NRPC] Problem encrypting data when use AES based Netlogon SChannel
Hi, According to MS-NRPC pg 111, bit 17 (indicated as bit R) of negotiable flag is actually referring to supports the NetrServerPasswordSet2 functionality. In the packet trace that attached earlier, I had successfully negotiated the session key (from pkt 519-523) with the DC using unprotected RPC and established the SChannel. However, when sending the encrypted message (encrypted with AES-key derived from the session key) over Schannel to DC, DC responded with DCE RPC fault with error = 0x0721. And, I also tried to use the initialization vector constructed using the last block (size=8 bytes) of the encrypted Confounder field, same error code returned from DC. There's no problem if only integrity is negotiated. So, I suppose the ivec mentioned in the MS-NRPC spec to encrypt the message might not correct ? Take a look at this branch, it contains working code, at least it worked a year ago against w2k8r2. http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-schannel Maybe that helps. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] [REG:110011477385004] RE: userParameters attribute
Am 23.05.2011 05:50, schrieb Andrew Bartlett: On Mon, 2010-06-21 at 22:54 +, Hongwei Sun wrote: Andrew, Sorry about the delay to give you a confirmation. We have been spending time to review the usage of UserParameters in other Windows components based on the information you provided. We found that this attribute is indeed still used by at least one other Microsoft product, such as RAS Server. The related product team is working on this to find how to document it. During my vacation, I will ask one of my team member (Obaid) to monitor the progress and send you the update when it is available. Out of pure curiosity, did this ever turn into documentation? BTW: is it documented that the userParameters attribute is stored as utf8 string, while the samr interface uses UTF16? See https://bugzilla.samba.org/show_bug.cgi?id=8077 (I haven't uploaded examples, but I plan to do so in the next weeks) metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 110080417580961] [MS-BKRP] 3.1.4.1 misc 0x00020000 value
Hi Matthieu, Issue verbatim -- So page 31 of MS-BKRP.pdf state that the message format for exchange is : NET_API_STATUS BackuprKey( [in] handle_t h, [in] GUID* pguidActionAgent, [in, size_is(cbDataIn)] byte* pDataIn, [in] DWORD cbDataIn, [out, size_is(,*pcbDataOut)] byte** ppDataOut, [out] DWORD* pcbDataOut, [in] DWORD dwParam ); I already asked if there is not some bytes after the dwParam. After analyzing the out message I have the impression that before the ppDataOut there is some kind of integer. Here is the hex dump of an output message: 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4 |De..| 0010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4 |l.bH...z...| 0020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c |K..t.gO...9,| 0030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24 |T..`...Io.5..#$| 0040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00 |Q.N.7i..D...| 0050 00 00 00 00 || 0054 so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut variable that is NDR encoded (meaning that the size is specified before on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00 0x00 0x00) and then the return code. I attach the out message extracted from the trace I sent last time. With the following samba idl: [public,nopush,nopull,noprint] WERROR bkrp_BackupKey ( [in,ref] GUID *guidActionAgent, [in,ref] [subcontext(4)] uint8 *data_in, [in] uint32 data_in_len, [in] uint32 param, [out] uint32 misc, [out] DATA_BLOB secret, [out] uint32 data_out_len ); We have the following result while using our ndrdump tool: pull returned NT_STATUS_OK bkrp_BackupKey: struct bkrp_BackupKey out: struct bkrp_BackupKey misc : 0x0002 (131072) secret : DATA_BLOB length=68 data_out_len : 0x0044 (68) result : WERR_OK dump OK As I have also managed to get a correct BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on the out message there is also something (that I named misc in our idl) (see the get_key_out file which is the extraction of out message on a BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I extracted seems to be correct I pretty encline to think I am right as first we are able to parse the NDR encoded data, and that the result seems sensible. Can you see if my analysis is correct and if so can you give us the explanation of this misc parameter. If not, well please tell me the correct way to parse the message. The misc parameter is the unique pointer. [out, size_is(,*pcbDataOut)] byte** ppDataOut means a the first pointer is [ref] and the 2nd pointer is (pointer_default() of the interface, unique in this case) And the unique pointer points to an array of bytes with size *pcbDataOut. metze signature.asc Description: OpenPGP digital signature ___ 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
Edgar, sorry I'm busy with other stuff currently. Stefan, I am just following up on this request to collect the TTT trace on this issue. We will need the trace to pursue the investigation. We have not observed behavior (of 255 bytes Name Length) between Windows-based WINS replication partners. I'll try to produce it next week. metze -Original Message- From: Edgar Olougouna Sent: Friday, February 12, 2010 12:09 PM To: Stefan (metze) Metzmacher Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Stefan, Regarding the issue you raised on replicating a name with a length of 255, we have not observed the behavior between Windows-based WINS replication partners. We need you reproduce the issue in your environment and send us the network trace and time travel tracing (TTT). I created the following workspace and uploaded the TTT utility for you: Workspace location: (https://sftus.one.microsoft.com/choosetransfer.aspx?key=0591488a-b578-409a-88df-288aaf6cdf1f) Password: i...@zy!ikccrmy3 Please collect the traces per these instructions: 1. Run the TTTSetup_x86_external.msi to install capture utility on Windows 2008 WINS server. 2. Open a command prompt and CD to your TTT folder ( ex. cd C:\Debuggers\ttt ) 3. If running on Vista/Windows Server 2008 or later make sure to run the following command from and elevated command prompt the first time after a reboot: TTTracer –initialize This will install the driver that is used to capture the data. 4. Find process ID for WINS.EXE process. You can use Task Manager to do this. 5. Type this command for each process, using a separate cmd prompt for each process we are attaching to: TTTracer.exe -attach pid -dumpFull pid is the process id of the wins.exe process. You should see a small dialog box pops up that has the title wins01.run. 6. Start network capture, e.g. by using Wireshark or Network Monitor. 7. Reproduce the problem. 8. Uncheck “Tracing on” in the dialog box and dismiss them. At this point you should see an .out file and a .run file under your ttt folder. 9. Upload the .out and .run files, along with the corresponding network trace on the workspace. Best regards, Edgar -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, February 04, 2010 1:19 PM To: Edgar Olougouna Cc: Bill Wesse; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Edgar, Could you send me which build of Windows 2008 you ran the tests corresponding to the network traces you provided? To determine the version, service pack and build number: Start Run msinfo32 On the System Summary, the Version item provides that information. Microsoft Windows Server 2008 Standard 6.0.6001 Service Pack 1 Build 6001 It's the 32-Bit Version. metze Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Monday, February 01, 2010 9:39 AM To: Stefan (metze) Metzmacher; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [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
Re: [cifs-protocol] Bug in MS-WINSRA section 2.2.10.1 Name Record
Hi Edgar, Could you send me which build of Windows 2008 you ran the tests corresponding to the network traces you provided? To determine the version, service pack and build number: Start Run msinfo32 On the System Summary, the Version item provides that information. Microsoft Windows Server 2008 Standard 6.0.6001 Service Pack 1 Build 6001 It's the 32-Bit Version. metze Best regards, Edgar -Original Message- From: Edgar Olougouna Sent: Monday, February 01, 2010 9:39 AM To: Stefan (metze) Metzmacher; Bill Wesse Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: Bug in MS-WINSRA section 2.2.10.1 Name Record Hi Stefan, I am taking care of this case and will update you as soon as I have news. Best regards, Edgar -Original Message- From: Bill Wesse Sent: Saturday, January 30, 2010 7:37 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org; Edgar Olougouna Subject: [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. signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] How to get the expanded group memberships for a user
Hi Edgar, I am looking into this and will update you on my progress. Any updates? metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Hi Hongwei, I think that Nick already informed you that AES 128 with 8 bit CFB mode has to be used. I filed a request to add the information into 3.1.4.4 of MS-NRPC. I also noticed that in mxnrpc.c you attached , you used AES_cfb128_encrypt() (128 bit CFB mode) for computing server credential. Please let us know if you have resolved the issue and if we can provide further help. Yes, he does and we got that part working. Thanks! using AES_cfb8_encrypt() instead of AES_cfb128_encrypt(). However we have the next challenge, the Netlogon SSPI provider. I used tried both AES_cfb8_encrypt() and AES_cfb128_encrypt() but both don't work. Looking at the frame 308 and the following in w2k8r2rc-l4-w2k8r2-trust-aes-schannel-01.pcap. I think there's a bug in w2k8r2 in the docs. The NL_AUTH_SHA2_SIGNATURE is filled in with very strange values. It seem that the checksum is still 8 byte and the confounder directly follows. The last 24 bytes are just uninitalized memory. They are: Frame 308: 32 00 2e 00 33 00 31 00 2e 00 39 00 2e 00 32 00 31 00 34 00 00 00 00 00 Frame 310: 35 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 Frame 311: (I think it's random because the pdu is so long and point memory in other aeas) 51 03 21 9b 41 84 cc 90 e7 e8 70 1c 52 60 55 5a 64 0c 6a 17 be 07 de 80 Looks like a unicode string instead of parts of a checksum and a confounder. metze Meanwhile, I provide some sample values that I captured from debugger for you to verify your logic. OWF Password : 13 c0 b0 4b 66 25 0d 08-b8 a3 90 4d cc 8b 34 e3 Client Challenge: 25 63 e3 5f 69 e1 5a 24 Server Challenge: 9C 66 5F 90 D9 83 DF 43 Session Key calculated: c9 c7 f7 2f c6 b9 13 e3-67 ae a9 1d 0a e3 a7 70 Client Credential: 58 6a df 53 ef 72 78 d9 Server Credential E1 41 62 09 B2 3E 57 51 It would be great if you could add this values to the docs. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Hongwei, A quick clarification for the AES bit in Negotiate Flag, as shown in 3.1.4.2. The information in the document regarding this bit is wrong. Bit W NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x0040) is not supported in Windows 7/Windows Server 2008 R2. The right bit to negotiate AES support should be NETLOGON_NEG_SUPPORTS_AES(0x0100), as you already indicated. If you use bit 0x0040 to negotiate the AES support, it might be the source of your problem. I was already only using the correct bit. I will file a request to fix this problem in the document. Meanwhile, I will work on the AES encryption details for Schannel. Thanks! metze -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, August 28, 2009 12:00 PM To: Hongwei Sun Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] MS-NRPC: AES Schannel problems Stefan (metze) Metzmacher schrieb: Hongwei, The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password. The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations. The SharedSecret is stored in UnicodePwd AD attribute. Please see section 3.1.1 and Windows Behavior notes 66,67 of MS-NRPC for details. Yes, I saw that and that's why I've also done it like this, but I was wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key and the des session key. I think it would make sense to also add it to the hmac_sha256 section in order to remove the confusion I had. I will continue working on all questions related to AES encryption. Thanks, as it seems I compute the session key correct, this is the place (netlogon_creds_step_crypt()) where I have a bug, because I'm getting access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server. Please also provide details about the aes encryption used when schannel acts as security provider for dcerpc. I noticed that the documentation on has only the NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x0040) flag, but w2k8r2 used the new flag NETLOGON_NEG_SUPPORTS_AES(0x0100). I assume the docs may missing also some crypto details, because of this... metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [Pfif] MS-NRPC: AES Schannel problems
Stefan (metze) Metzmacher schrieb: Hongwei, The SharedSecret used for AES session key computation, as described in 3.1.4.3 MS-NRPC , should be the NTOWF (MD4(UNICODE(Passwd))) of the plaintext password. The section 3.1.1 of MS-NRPC explains what a SharedSecret is used for session key calculation in Windows implementations. The SharedSecret is stored in UnicodePwd AD attribute. Please see section 3.1.1 and Windows Behavior notes 66,67 of MS-NRPC for details. Yes, I saw that and that's why I've also done it like this, but I was wondering why Section 3.4.1 has M4SS := MD4(UNICODE(SharedSecret)) explicit for the hmac_md5 session key and the des session key. I think it would make sense to also add it to the hmac_sha256 section in order to remove the confusion I had. I will continue working on all questions related to AES encryption. Thanks, as it seems I compute the session key correct, this is the place (netlogon_creds_step_crypt()) where I have a bug, because I'm getting access denied when I try DCERPC_SCHANNEL_AES against a w2k8r2rc server. Please also provide details about the aes encryption used when schannel acts as security provider for dcerpc. I noticed that the documentation on has only the NETLOGON_NEG_SUPPORTS_AES_SHA2 (0x0040) flag, but w2k8r2 used the new flag NETLOGON_NEG_SUPPORTS_AES(0x0100). I assume the docs may missing also some crypto details, because of this... metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Status of [MS-RAIW]?
Hi, I got a draft for preview of the MS-RAIW document last december. I'm wondering when this will appear in the WSPP docs. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] CAR - SMB2 Write and Read in Windows 7
Hi Edgar, I have completed investigation on your request. Please find the answers below. 1. SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap: The scenario you described relates to SMB 2.002 clients issuing overly large writes. The Product Team confirmed a bug in the Windows 7 implementation regarding the return code STATUS_BUFFER_OVERFLOW instead of STATUS_INVALID_PARAMETER as documented in [MS-SMB2] 3.3.5.13. The fix is planned to be available in SP1. This issue is minor and we may not provide a patch prior to that, since it requires a client to send an invalid request, thus not following the protocol. There will be a Windows behavior note similar to this (not exactly this wording): WB The STATUS_BUFFER_OVERFLOW is returned for read/write exceeding max read/write size since Vista and we will correct it in Windows 7 SP1. 2. SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap: Based on the clarification provided by the new network trace I requested (SMB2-CONNECT-w7rc-smb2.002.writesize-not-strange-03.pcap), we came to the conclusion and agreement to rule out the truncation claim of your original request. The behavior in the new trace is consistent and expected. 3. SMB2-CONNECT-w7rc-smb2.100.writesize-01.pcap: This scenario relates to SMB 2.1 clients issuing writes with MaxWriteSize over 64KB. The behavior you experienced is expected per multi-credit (large MTU) operations, a new capability introduced with SMB 2.1 dialect. The CreditCharge for a request is used for requests larger than 64 KB, and the credits consumed is equal to the (RequestLength rounded up to 64k boundary) / 64k. For instance, a 65 KB request would require 2 credits, etc. Supplying insufficient credits will cause the operation (by design) to fail with INVALID_PARAMETER since the request is mal-formed. In the near future, an RTM release of the MS-SMB2 document that specifies SMB2.1 multi-credit (large MTU) operations will be available. In the interim, the following resources provide relevant information on the topic: * Blog post: SMB 2.1 Multi-Credit (Large MTU) Operations http://blogs.msdn.com/openspecification/archive/2009/06/22/smb-2-1-multi-credit-large-mtu-operations.aspx * Channel9 presentation: Server Message Block (SMB2.1) Drill-down http://channel9.msdn.com/posts/Darryl/Server-Message-Block-SMB21-Drill-down/ You may also receive information concerning document update postings by subscribing to the e-Newsletter - Microsoft Open Protocols at http://www.microsoft.com/protocols/e-newsletter/. Thanks, I understand how it's supposed to work now. metze Best regards, Edgar A. Olougouna Sr. SEE, Microsoft DSC Protocol Team -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Wednesday, July 08, 2009 3:22 AM To: Edgar Olougouna Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: Re: CAR - SMB2 Write and Read in Windows 7 Hi Edgar, While investigating your inquiry, we would like to request more data to help fully scope the issues. We believe we correctly understand the issues you reported in two of the three network traces: - SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap - SMB2-CONNECT-w7rc-smb2.100.writesize-01.pcap Regarding the SMB 2.002 Write scenario exhibited in the network trace SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap: Frame 26 and Frame 28 indicate a file size of 65536 when it is opened, and this does not suffice to prove or conclude that the write with the invalid length 65537 did the truncation write. Allocation Size: 65536 End Of File: 65536 To help clarify this, we need another trace of a slightly different testing of this scenario: - First, issue a success write (say write length 65536), - Second (following the success write), issue an invalid write (say write length 65537 with offset 65536) to see whether the file length becomes 131072 after the second write fails. You're right, the tests missed to delete the file at startup, so that the behavior of the test is consistent. The attached capture isn't so strange anymore, the GetInfo after the write reports allocation size and end of file as 0. And the read gets NT_STATUS_END_OF_FILE. So it's just the different error code. metze From: Edgar Olougouna Sent: Monday, July 06, 2009 11:08 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: CAR - SMB2 Write and Read in Windows 7 Hi Stefan, I have taken ownership of this case and will be working with you for its resolution. Best regards, Edgar A. Olougouna Sr. SEE, Microsoft DSC Protocol Team Hi, I'm working on SMB2 support for Samba and noticed a strange behavior regarding the maximum read and write sizes in SMB2. Section 3.3.5.13 Receiving an SMB2 WRITE Request says the server must return
Re: [cifs-protocol] Re: CAR - SMB2 Write and Read in Windows 7
Hi Neil, There are still a bunch of people working on getting good answers to you. But in brief the over 64K writes when SMB 2.1 is negotiated uses a feature called multi-credit. An updated MS-SMB2 document is to be published next week on MSDN (that was scheduled before your issue was raised) that describes that feature. So without jumping the gun too much, one thing is clear. The way torture works for over 64K writes with SMB2.1 dialect needs to be tweaked as that is a condition where multi-credits apply. There may still be issues with the way Windows 7 behaves - that is one of the thing that is being checked. Thanks for the update! Would it be possible to get a preview of this document (as we already got in the past). (If it can't be made public, then maybe only post it to the private p...@tridgell.net list and to me directly.) metze -Original Message- From: cifs-protocol-bounces+neilm=thetestplace.co...@cifs.org [mailto:cifs-protocol-bounces+neilm=thetestplace.co...@cifs.org] On Behalf Of Stefan (metze) Metzmacher Sent: Wednesday, July 08, 2009 9:22 AM To: Edgar Olougouna Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: [cifs-protocol] Re: CAR - SMB2 Write and Read in Windows 7 Hi Edgar, While investigating your inquiry, we would like to request more data to help fully scope the issues. We believe we correctly understand the issues you reported in two of the three network traces: - SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap - SMB2-CONNECT-w7rc-smb2.100.writesize-01.pcap Regarding the SMB 2.002 Write scenario exhibited in the network trace SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap: Frame 26 and Frame 28 indicate a file size of 65536 when it is opened, and this does not suffice to prove or conclude that the write with the invalid length 65537 did the truncation write. Allocation Size: 65536 End Of File: 65536 To help clarify this, we need another trace of a slightly different testing of this scenario: - First, issue a success write (say write length 65536), - Second (following the success write), issue an invalid write (say write length 65537 with offset 65536) to see whether the file length becomes 131072 after the second write fails. You're right, the tests missed to delete the file at startup, so that the behavior of the test is consistent. The attached capture isn't so strange anymore, the GetInfo after the write reports allocation size and end of file as 0. And the read gets NT_STATUS_END_OF_FILE. So it's just the different error code. metze From: Edgar Olougouna Sent: Monday, July 06, 2009 11:08 AM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: RE: CAR - SMB2 Write and Read in Windows 7 Hi Stefan, I have taken ownership of this case and will be working with you for its resolution. Best regards, Edgar A. Olougouna Sr. SEE, Microsoft DSC Protocol Team Hi, I'm working on SMB2 support for Samba and noticed a strange behavior regarding the maximum read and write sizes in SMB2. Section 3.3.5.13 Receiving an SMB2 WRITE Request says the server must return STATUS_INVALID_PARAMETER if the length isn't in the configured range (which is reported to the client in the NEGOTIATE response). The same applies to SMB2 Read requests. However a Windows 7 server doesn't behave like this. (I tested this with Windows 7 RC Build 7100). I've attached 3 network captures to this mail, which demonstrate the wrong behavior. SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap: - We run our SMB2-CONNECT torture test like this: bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \ SMB2-CONNECT --option=torture:smb2maxwrite=65537 (I manually excluded the SMB 2.100 dialect in our code) - In Frame 5 SMB 2.002 is negotiated and the server returns MaxReadSize and MaxWriteSize as 65536 (0x0001). - The Frames 17-71 (wireshark reassembles them in Frame 71) there's a SMB2 Write request with length 65537 (0x00010001). - And the SMB2 Write response in Frame 72 returns STATUS_BUFFER_OVERFLOW instead of STATUS_INVALID_PARAMETER. (Then our test closes the tcp connection) - Now we run our SMB2-CONNECT torture test like this: bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \ SMB2-CONNECT --option=torture:smb2maxwrite=65536 - The SMB2 Write response in Frame 147 returns STATUS_OK, which is correct. - Also the SMB2 Read response (reassembled) in Frame 285, gets STATUS_OK. SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap: - Here I manually modified the write/read sizes in the SMB2-CONNECT torture test and ignored any errors. So that we write 65537 bytes and read 65536 bytes. (I also manually excluded the SMB 2.100 dialect in our code) - The SMB2 Write request (reassembled in Frame 142) writes 65537 bytes and gets STATUS_BUFFER_OVERFLOW. - The SMB2
Re: [cifs-protocol] Sharing /home with Samba/CIFS
Hi Tom, the cifs-protocol mailing list is for technical discussions about protocol details, please use [EMAIL PROTECTED] for samba related user questions. metze I would like to use Samba to share the /home directory from one machine to another. So, I need the following to work: 1. In the share, any file created by a user needs to be owned by that user. 2. The system needs to obey the SGID bit for directories, which means: a. Any file created in a directory with SGID set, will inherit the directory's group ownership. b. Any directory created in said directory will inherit the group ownership, and also have its SGID bit set. On the server, I am running Samba 3.0.22 on a 2.6.18.1 kernel. On the client, running Linux 2.6.24, mount.cifs reports version 1.10-3.0.28a. I started by simply mounting the share using mount.cifs as root. Unix extensions are turned on at the server, so I figured everything would just work. Unfortunately, it did not. The primary problem is that new files created by a user do inherit the group of SGID parent directories, but the owner is always set to root. This is a slight problem. I tried setting the setuids option on the server, but this simply results in new files always having the user ID and group ID set to the owner, indiscriminately, completely ignoring the SGID bit of the parent directory. Can I get this to work somehow? P.S. Yes, I tried NFS, which is what is normally used for this sort of thing, but unfortunately many of the users belong to more than 16 groups, which breaks NFS3. NFS4 supposedly solves this, but it doesn't work properly on the 2.6.18.1 kernel that I am stuck with on the server. signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
Hi Hongwei, We finished adding an example for GSS_WrapEx with AES128-CTS-HMAC-SHA1-96 in [MS-KILE]. The attached PDF document is the newly added section(4.3) of the [MS-KILE] document. We really appreciate your suggestion. Please let us know if you have further questions regarding this subject. It would be nice if this example would use ec != 0, as that was exactly not match RFC 4121 and the reason our (heimdal) krb5 code was not able to handle network traffix from windows. You should unify the naming of the resulting overhead, in the diagramm you use 'checksum' and in the test you use 'signature', maybe 'token' would be the better word here, as 'checksum' is a non unique in the diagramm. An example with arcfour-hmac-md5 would also be very useful, as there the pseudo ASN.1 wrapping arround the token is very tricky. As it's only arround the 'token' instead of 'token' + 'message' + 'padding' as it is for the standard GSS_Wrap function. Also it would be nice to have a specific example how the RPC layer calls GSS_WrapEx. It would also be very helpfull to know how the mapping to the SSPI function parameters works. metze -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 6:24 AM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES On Tue, 2008-08-26 at 08:50 -0700, Hongwei Sun wrote: Andrew, In this case, you provided a diagram for us to add to the document and metze added some comments. Thanks for your contribution to our documentation and continued feedback. The product team reviewed the diagram and comments provided. We believe that the diagrams imply interaction between elements and without detailed notes they are subject to multiple interpretation and hence confusion.We believe that as a matter of providing deterministic documentation, we would prefer to provide specific examples. We'll be happy to get your feedback on creating examples and send them for your review once they are ready. A visual description of how the RRC interacts with the AEAD behaviour and the subsequent placement of the trailer in the header will be critical. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ Pfif mailing list [EMAIL PROTECTED] http://lists.tridgell.net/cgi-bin/mailman/listinfo/pfif ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Session keys are not always 16 bytes long
Hi Hongwei, The product team confirmed that Windows servers always truncate session keys to 16 bytes for signing. As per previous e-mail, your SMB signing has to use entire 32 bytes of AES session key for signing. Do your newly found bugs affect this statement ? No, I still believe that all 32 bytes of the session key are needed. metze Thanks ! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 10:57 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Metze, When you tested SMB signing with 32 byte AES session key, did you test Vista with Samba server , Samba client with Windows server or both ? Samba as client and Windows 2008 as server. I found a few bugs in Samba's smb signing implementation. Windows only signs the last session setup response and samba also signs the last session setup request. I have some hacks which fix samba, but I haven't done a clean implementation yet. The key thing is that the client needs to process the last session setup response first and then verify its signature after when the correct session key is avaliable. metze -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 3:25 PM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121).When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Session keys are not always 16 bytes long
Hongwei Sun schrieb: Metze, When you tested SMB signing with 32 byte AES session key, did you test Vista with Samba server , Samba client with Windows server or both ? Samba as client and Windows 2008 as server. I found a few bugs in Samba's smb signing implementation. Windows only signs the last session setup response and samba also signs the last session setup request. I have some hacks which fix samba, but I haven't done a clean implementation yet. The key thing is that the client needs to process the last session setup response first and then verify its signature after when the correct session key is avaliable. metze -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 3:25 PM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] Session keys are not always 16 bytes long Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] FW: SAMBA4 Test suite interoperability testing in preparation for the upcoming event.
Hi Darryl, As we discussed, you recommended that Stefan review the RPC issue below identified during initial test results from a few test scenarios.As noted by the test suite developer below, this required the test suite to bind w/o the UUID. could you please send me that network captures (and the maybe needed keytab) Thanks! metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Re: [Pfif] Other types of Kerberos messages on SamLogon Generic
Hongwei Sun schrieb: Andrew, We ran Smbtortue RPC-PAC testing on windows 2008 DC and got the following output. [EMAIL PROTECTED] source]# bin/smbtorture -k yes //VM-W2K8.nick.com/public RPC-PAC Using seed 1220896649 Running PAC Password for [NICKDOM\root]: Domain join failed - Connection to SAMR pipe of DC VM-W2K8.nick.com failed: Connection to DC VM-W2K8.nick.com failed: NT_STATUS_UNSUCCESSFUL Setup failed: torture/rpc/rpc.c:144: Failed to join as BDC PAC took 11.264 sec I assume you're getting a clock skew error. Make shure the clock is in sync. We have a hacked patch to handle clock skew error more nicely, but it's not in our upstream code yet... metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Re: [Pfif] How are 'supported enc types' determined in trusts? - 600253
Richard Guthrie schrieb: Andrew, If you have a windows 2008 server acting as a member server in a downlevel domain (for this discussion we will assume 2003 functional level), this attribute will only exist if you extend the schema to a level that is compatible with 2008 functional level. This is a normal step as part of an upgrade from Windows 2000 - 2003 or Windows 2003 - 2008. The following kb article describes this process in more detail http://technet.microsoft.com/en-us/library/cc773360.aspx. It will show up in the schema for computer accounts as well as being an attribute on objects where objectClass == trustedDomain. It does not matter if the domain controller is still Windows 2003, the computer account and TDO will have this attribute. The value of this attribute will show up as 'Not Set' in a tool such as ADSIEdit (see attached msds-SupportedEncryptionTypes.zip). This is the same as saying the attribute is null. It will not be in use until the domain functional level is set to 2008. Setting the functional level to 2008 requires that all the domain controllers be upgraded to Windows Server 2008. Schema version can be set independently of the functional level to facilitate seamless upgrade scenarios. As to your second question, this attribute value is not dependent on trust type/attribute flags. It also will not have a value unless someone explicitly sets it. In the case of computer accounts this attribute is set by netlogon during secure channel initiation. Can you explain that process a bit further, please? metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Session keys are not always 16 bytes long
Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121). When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] Session keys are not always 16 bytes long
Andrew Bartlett schrieb: On Fri, 2008-09-05 at 22:25 +0200, Stefan (metze) Metzmacher wrote: Hongwei Sun schrieb: Metze/Andrew, The subkey in the EncAPRepPart of the AP-REP should be used as the session key when the mutual authentication is enabled(as described in RFC 4121).When DES and RC4 are used in Kerberos, the implementation is based on RFC1964 (instead of RFC4121). According to RFC1964, you can pick the subkey in AP_REQ as the session key as it is the same as the subkey in AP_REP, but this is not true when AES is used because both subkeys are different (again AES means RFC4121 being used, not RFC1964). This explains what you observed. We will add the information to [MS-KILE] to describe how the session key is selected. The session key returned from Kerberos package can be used for SMB signing as described in the section 4.3 of [MS-SMB]. You have to truncate the keys to 128 bits in your code because SMB does the truncation on the windows side. I ran the similar testing as you did. I had one Vista machine connected to Windows 2008 DC/KDC and configured AES256-CTS-HMAC-SHA1-96 as Kerberos encryption type with mutual authentication enabled. I cannot duplicate your SMB signing problem(see the network capture attached). It is working between Windows servers and clients. I got it working, the session key isn't truncated for the SMB signing. The problem was that we reseted the sequence number when updating the session key from the initiator subkey to the acceptor subkey between the session setup request and response. Also windows signs the response with the acceptor subkey, so that the client needs to check the signature after processing the response. I think I hit the same issue Samba/Samba last night (after I enabled mandatory smb signing in our server). Is your fix for this up somewhere? http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=v4-0-aes http://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=b53e6387e30010509034835acf88b91b380ff44a metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] Re: Answer: SRX080626600802 : WINS administrative RPC interface
People on the mailing lists, would it make sense to receive the newsletter via the mailing list, so that each of us don't have to subscribe to it. metze Bill Wesse schrieb: Thank you! Per the below, information on document updates is available through an e-newsletter. You can sign up to receive the Protocols Perspective e-Newsletter Each month you’ll receive helpful information about: Protocol Documentation Updates Patent License Program Other Licensing Programs Community Events Helpful Tips Licensee Case Studies http://www.microsoft.com/about/legal/intellectualproperty/protocols/optin.aspx Wp Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: 980-776-8200 CELL: 704-661-5438 FAX: 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: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2008 4:50 AM To: Bill Wesse Cc: [EMAIL PROTECTED] Subject: Re: Answer: SRX080626600802 : WINS administrative RPC interface Bill Wesse schrieb: Good morning Mr. Metzmacher. I am resending this, since I have not received a response from you. This is in regards to your request that we document the 'WinsPipe' (WINS Server Service API) named pipe interface. We plan to document the remote administrative RPC interface to WINS as part of our Interoperability principles. The documentation will be made available in a new protocol document. At this time the documentation is in the early stages of development. We will make the documentation available in a future documentation refresh. 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. I'm happy when the document is available online. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] DCE_STYLE, AES and sequence numbers
Andrew Bartlett schrieb: The documentation in MS-KILE 3.4.5.1 on DCE_STYLE is very terse, and fails to clarify a few points, one of which is preventing interoperability with Windows Vista. The client MUST generate an additional AP reply message exactly as the server would ([RFC4120] section 3.2.4) as the final message to send to the server. In GSS terms, the client must return success and a message to the server. It is up to the application to deliver the message to the server. The server MUST receive the additional AP reply message and verify that the message is constructed correctly ([RFC4120] section 3.2.5). What is unclear here is how the sequence numbers, exchanged in this message, are expected to be updated. For example, with a WinXP clients, and arcfour-hmac-md5 encryption, the sequence number (as maintained by the client, and seen on the server) is unaffected by the receipt of this extra message. In Heimdal's implementation here, we reset the sequence numbers after verifying the AP_REP at line 690. http://git.samba.org/?p=samba.git;a=blob;f=source/heimdal/lib/gssapi/krb5/accept_sec_context.c;h=73b93ceba4c6bb472c546afd52981bcf13051173;hb=v4-0-test However, when GSSAPI CFX is used, and therefore an AES key is negotiated by a Windows Vista client to a Samba4 server, the client seems to require that the remote (from the server's persective) sequence number be increased by 1. (ie, adding 1 to r_seq_number at like 690 allows the next gss_unwrap to match the expected sequence number correctly, in the DRSUAPI bind portion of a Vista SP1 domain join). I found why the seq number needs is +1, it's because there's a GetMIC token in the AlterContext request from the client, in the same SPNEGO blob as the AP-REP from the client. And our server seems to miss the call to gss_verify_mic(), which would increase the seqnum. metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
Hongwei, The encryption function in Kerberos is described in details in 5.3 [RFC3961] (http://www.ietf.org/rfc/rfc3961.txt), which is referenced by [MS-KILE]. I can summarize as follows * conf is actually a random confounder prefix of length c ,such as 16. * pad is for shortest padding to bring confounder and plaintext to a length that is the multiple of message block size m, which is octet(8) for AES encryption, as specified in section 6 [RFC 3962] (http://www.ietf.org/rfc/rfc3962.txt) * Ke is an encryption key and Ki is a checksum key. * Plain text is the input confidential data before encryption. * The GSSWrapEX() is exactly the same as the GSSWrap except that it supports ordered list of input buffers. Input buffers for which conf_req_flag == TRUE are encrypted and returned. Buffers which sign == TRUE are included in the signature. It would be extremly useful if the MS-RPCE document would explain what the exact input buffers to GssWrapEX() are and what flags are used in each of the cases (with and without header signing). Then it would be useful to know to what exactly SSPI EncryptMessage call this is mapped. And finally how each of the of the encryption types (des-*, arcfour-hmac-md5, and aes-*) are supposed to process the EncryptMessage input. It would be nice if you could use a realistic example, with explicit values. A bit like the A.5 Test suite section of RFC1321 - The MD5 Message-Digest Algorithm. metze * We use the Kerberos standard's encryption and signatures.It is very important to concatenate the correct buffers to make it work. Please let me know if further clarification is needed and I will be happy to assist you. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Monday, July 28, 2008 12:53 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES I've been spending most of today staring at MS-KILE 3.4.5.4.1 and Heimdal's implementation of GSSAPI CFX. What has me stumped is exactly what this means: If the session key encryption type is AES128-CTS-HMAC-SHA1-96 or AES256-CTS-HMAC-SHA1-96, as specified in [RFC3961], the base line is [RFC4121] and the encrypted data per [RFC3961] (which [RFC4121] is based on) is: C1 | H1[1..h] Where (C1, newIV) = E(Ke, conf | plaintext | pad, oldstate.ivec) H1 = HMAC(Ki, conf | plaintext+encrypted-data | pad) where the plaintext+encrypted-data is all the input data buffers supplied to GSS_WrapEx() concatenated in the order provided in the ordered list, input_message. It would be extremly useful if the MS-RPCE document would explain what the exact input buffers are and I see that C1 is the output of the encryption function E, and presume that Ke is the encryption key, but what is 'conf', and is 'plaintext' the confidential data in plaintext, or the data over which only a signature is computed (presumably the confidential data in plaintex, but then what is conf)? I presume again that Ki is the signing key. Likewise, a description of how the pad fits into the HMAC function here would be very helpful. In short, because this is a deviation from the GSSAPI spec (as the spec does not allow data to be signed, but not sealed), I really need much more detail, and all the inputs and outputs clearly labelled, particularly as this seems to require a major rework of Heimdal to implement :-( Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ Pfif mailing list [EMAIL PROTECTED] http://lists.tridgell.net/cgi-bin/mailman/listinfo/pfif signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
