We don't return access denied when wrong user tries to reconnect to durable handle. 2015-02-25 20:08:52.584 [TestInProgress] Microsoft.Protocols.TestSuites.FileSharing.SMB2.TestSuite.DurableHandleV2.DurableHandleV2_Reconnect_WithDifferentDurableOwner 2015-02-25 20:08:52.600 [Comment] Test reconnect with DurableHandleV2 and different durable owner. 2015-02-25 20:08:52.669 [Comment] Client connects to server and opens file with a durable handle 2015-02-25 20:09:00.349 [Comment] Client opens the same file and reconnects the durable handle CREATE should not be successful if the DurableOwner is different, actually server returns STATUS_OBJECT_NAME_NOT_FOUND. 2015-02-25 20:09:04.969 [CheckFailed] Assert.AreEqual failed on requirement MS-SMB2_R4. Expected: <3221225506>, Actual: <3221225524>. Server should return error STATUS_ACCESS_DENIED 2015-02-25 20:09:04.976 [Comment] at Microsoft.Protocols.TestTools.DefaultTestSite.CaptureRequirementIfAreEqual[T](T expected, T actual, Int32 requirementId, String description, RequirementType requirementType) 2015-02-25 20:09:05.255 [TestFailed] Microsoft.Protocols.TestSuites.FileSharing.SMB2.TestSuite.DurableHandleV2.DurableHandleV2_Reconnect_WithDifferentDurableOwner
Created attachment 10795 [details] wireshark trace to Samba 4.2 of durable handle reconnect Note frame 47 should have returned access denied
Created attachment 10796 [details] wireshark trace of Windows 2012R2 handling this correctly and returning access denied
Created attachment 10797 [details] fix to return access denied when wrong user reconnects to durable handle tested with Microsoft automated tests and fixes the problem with the durable reconnect tests
See MMS-SMB2 section 3.3.5.9.7 10.If the user represented by Session.SecurityContext is not the same user denoted by Open.DurableOwner, the server MUST fail the request with STATUS_ACCESS_DENIED and proceed as specified in "Failed Open Handling"
Looks like this hasn't been merged/fixed, need to rerun test to make sure.