RE: [cifs-protocol] RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional
Stefan, Thanks for working with us in the lab on this to find the root cause. The root cause was determined to be a bug in the Samba test code related to header signing when SpNegotiate was used. Please let us know if there are any further questions regarding this issue. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM Tel: +1 (469) 775-7794 E-mail: [EMAIL PROTECTED] 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: Tuesday, September 09, 2008 4:22 AM To: Richard Guthrie Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional Richard Guthrie schrieb: Stefan, The traces you sent seems to show a correct security context negotiation but something is failing when we go to use that context which is why we see RPC_NT_SEC_PKG_ERROR. I would like to start with getting some more detailed error info from the windows machine by doing the following: Enabling Extended Error Information. You can do this by following the steps in this msdn article http://msdn.microsoft.com/en-us/library/aa373803(VS.85).aspx and taking a network capture again. This is going to add some additional information in the response that will lead us to a more precise error message. If you can send me that trace with the associated keytab file, I can get further into what the problem is. See the attached capture... The error is this (windows 2003 generates the same, but with status = WERROR_ACCESS_DENIED (0x0005)) decode_ExtendedErrorInfo: struct decode_ExtendedErrorInfo in: struct decode_ExtendedErrorInfo ptr: struct ExtendedErrorInfoPtr info: * info: struct ExtendedErrorInfo next: NULL computer_name: struct ExtendedErrorComputerName present: EXTENDED_ERROR_COMPUTER_NAME_PRESENT (1) n: union ExtendedErrorComputerNameU(case 1) name: struct ExtendedErrorUString __size: 0x0009 (9) string: * string: 'w2k8-211' pid : 0x023c (572) time : Tue Sep 9 11:43:22 2008 CEST generating_component : 0x0003 (3) status : DOS code 0x0721 detection_location : 0x0082 (130) flags: 0x (0) num_params : 0x0003 (3) params: ARRAY(3) params: struct ExtendedErrorParam type : EXTENDED_ERROR_PARAM_TYPE_UINT32 (3) p : union ExtendedErrorParamU(case 3) uint32: 0x8009030f (2148074255) params: struct ExtendedErrorParam type : EXTENDED_ERROR_PARAM_TYPE_UINT32 (3) p : union ExtendedErrorParamU(case 3) uint32: 0x0009 (9) params: struct ExtendedErrorParam type : EXTENDED_ERROR_PARAM_TYPE_UINT32 (3) p : union ExtendedErrorParamU(case 3) uint32: 0x0005 (5) metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional
Andrew, As per your last mail, we agree this looks like a good scenario to target for the upcoming IO lab. As we have discussed, in order to not waste time on debugging setup while you are in the lab, we would need to work together prior to establish the correct repro environment. Establishment of this repro would require your expertise to ensure the environment accurately reproduces this issue. Let us know if this sounds like an acceptable action plan and we can work out the details on our next call together. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 8:48 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [cifs-protocol] RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional On Mon, 2008-08-11 at 08:41 -0700, Richard Guthrie wrote: Andrew, Can you send a capture that exhibits the behavior you describe with NTLMv2 as well as clarify your comments about behavior you have seen in the past? Basically I need as much information as you can provide on the behavior you have experienced to help understand the problem. This would help to isolate the behavior you are seeing and complete additional analysis as required. I will do, when I get a chance. We should also work to get Samba4 set up in the interop lab, so you can just run tests against it and see the behaviour live. 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
Re: [cifs-protocol] RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional
On Mon, 2008-08-11 at 08:41 -0700, Richard Guthrie wrote: Andrew, Can you send a capture that exhibits the behavior you describe with NTLMv2 as well as clarify your comments about behavior you have seen in the past? Basically I need as much information as you can provide on the behavior you have experienced to help understand the problem. This would help to isolate the behavior you are seeing and complete additional analysis as required. I will do, when I get a chance. We should also work to get Samba4 set up in the interop lab, so you can just run tests against it and see the behaviour live. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional
Andrew, The trace you sent previously lines up with expected behavior the documentation defines (This was also verified with a review of the code also). You can see starting with packet 530 that the client tells the server that it does support signing but the server responds in packet 534 that it does not. From there in frames 535-538 show the client and server not using header signing for the remainder of the conversation which is in line with the documentation. We do see the client and server encrypting the body of the request as per the authentication level being set to Privacy. Can you send a capture that exhibits the behavior you describe with NTLMv2 as well as clarify your comments about behavior you have seen in the past? Basically I need as much information as you can provide on the behavior you have experienced to help understand the problem. This would help to isolate the behavior you are seeing and complete additional analysis as required. Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7794 E-mail: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 5:26 PM To: Richard Guthrie Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: 600169 - RE: DCE/RPC PFC_SUPPORT_HEADER_SIGN not optional On Wed, 2008-07-30 at 08:45 -0700, Richard Guthrie wrote: Andrew, We have completed our review of your request to update the documentation and would like to point out the following text from MS-RPCE section 3.3.1.5.2.2. Using this mechanism, the client and server agree if header signing should be done for this connection. Once agreed, the client and server apply protection to request and response PDUs in the same way. Based on this verbiage as well as the trace you sent previously (Packet 537) the documentation is correct that this is flag is used to negotiate whether header signing or integrity checking will be used in conjunction with the set authentication level. The client will set this bit to 1 on the initial BIND and the server will then set it to 1 or 0 to negotiate whether header signing will be utilized on all subsequent request/response in the conversation according to the guidelines for authentication level in section 3.3.1.5.2.2. Please let us know if you have any further questions on this issue. No, this does not resolve the request. I agree that this is what reading the docs would tell you, but please consider this more deeply, and make enquires with the actual code (not the spec...) - please read Metze's and my additional observations and inquire into the code. We know that AEAD (Authenticated Encryption with Additional Data, aka header signing) which is what this feature is meant to negotiate is still used, because we have had to implement it for NTLM2, without setting either of these flags. 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
