Premature SMB/CIFS Session Close (System error 1312) with Password on SMBv2

Question

In attempting to issue a "net use" to a NetApp share, I'm experiencing a very unique situation.

A particular user is required to issue scans across a CIFS, however that user (which has full read/write access) receives a "System error 1312 has occurred - A specified logon session does not exist. It may already have been terminated."

That situation entails the following command:

net use \\ShareHostname\Share /user:DOMAIN\user /persistent:no [password]

The packet capture below displays this attempt.

In the event I issue the same command without providing a password for the currently logged in user (different than the required user and only has read access), the command completes successfully.

net use  \\ShareHostName\Share /user:DOMAIN\user2 /persistent:no

This problem originated when moving the application from a Win2k3 box to a Win2k8 on the same domain. The account that will not authenticate on the new machine does work on the Win2k3 machine, interestingly enough.

In checking, I verified that for both machines the GPO "Network access: Do not allow storage of passwords and credentials for authentication" is "Enabled" on both machines and cannot be changed.

I'm really at a wall trying to narrow down on this issue, and would greatly appreciate hints into extra troubleshooting steps or a possible resolution.

Edit:

• The only observed differences between the two systems are the communication to the NetApp via SMBv1 (Win2k3) to SMBv2 (Win2k8), obviously. However the real difference that breaks it is that when a password is supplied (no matter what the user) for SMBv2, the System Error 1312 occurs. But if no password is supplied (for the currently logged on user), then it will complete the authentication successfully.

Solution

Unfortunately there was no real solution to this problem, as NetApp does have a case open with Microsoft for Windows Server 2008 using SMBv2 or SMBv3.

The only workaround for this particular bug was to have the network Administrators disable the GPO setting for "Network access: Do not allow storage of passwords and credentials for authentication" which was not the original intent of opening a case with NetApp or posting on here.

For anybody who is interested, NetApp provided the following:

Bug ID: 837425

Bug Type: CIFS

Description: Under certain circumstances, attempts to connect to a CIFS share fail with the following error message: "System error 1312 has occurred. A specified logon session does not exist. It may already have been terminated."

The problem occurs for SMB 2 and SMB 3 Windows clients such as Windows 7, Vista, and Windows 8. The problem occurs when credentials are specified while connected to a share, such as the following example:

net use * \\server\share /user:domain\user password

The problem does not occur on SMB 1 clients such as Windows XP, so using SMB 1 clients to connect to share is a workaround. However, note that the problem still occurs for SMB 2 and SMB 3 clients like Windows 7 and Windows 8 even when SMB 2 and SMB 3 are disabled on the SVM and the clients connect using SMB 1.

Notes: When the fix for bug 746314 is available, it will serve as a workaround for this problem.

Comments

[Basil]

Is the Netapp running CDOT or 7-mode?

[Basil]

Also, if it's a double hop issue, you might want to check this link: ravichaganti.com/blog/…

[Basil]

I'm not putting this in an answer because it's a cop-out, but this problem is specific enough that you should probably open a case with Netapp.

[MadHatter]

You should probably accept this answer - it seems definitive, so I doubt a better one will come along, and it will stop the question floating around forever like a querulous albatross. +1 from me on both question and answer, by the way.

[Signus]

I'll go ahead and do that so it's not open any longer. I don't have access to those systems anymore and I don't have contact with the same team that I found the problem in. Thanks!

[Signus]

If you read my answer, that's exactly what I posted even though it was undesired and was a workaround. I no longer have access to that system or network to validate the problem ever disappeared.