SMB signing problem between Windows and NetApp?

I have a number of users in another building accessing our central storage as a mapped share, lets say drive Z:. Randomly (mostly just once a day, always at different times) one ore some of them loose the connection to Z:. They still see Z: in explorer but can't access any directory or file. These people are not always the same. These users are using (still) XP and most of them Win7. We checked IP connectivity, DNS resolution, switches and firewall. Nothing to take care of there. Just our NetApp is reporting some error messages.

Thu Mar 27 13:56:26 CET [storage-01: ems.engine.inputSuppress:error]: Event 'cifs.trace.smbSignMismatch3' suppressed 4 times since Wed Mar 26 12:36:17 CET 2014.
Thu Mar 27 13:56:26 CET [storage-01: cifs.trace.smbSignMismatch3:error]: CIFS: Request from client for operation 117 (tconX) was rejected because the client requested enforcement of security signatures (SMB signing) and the signature provided by the client did not match the value calculated by the filer.

Open in new window

We are running SMBv2 at NetApp.

There is another error message, where I'm not sure if it has something to do with my problem.

Thu Mar 27 09:33:41 CET [storage-01: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user pc08$ of domain DOMAIN from client machine (PC08).
Thu Mar 27 09:36:17 CET [storage-01: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000064: DC indicates user is not from a trusted domain.

Open in new window

Here I'm not sure if this message belongs to the one before. There is a gap of nearly 3 minutes.

Is there anybody out there who had solved such a problem in the past? Thanks for any hints.


Who is Participating?
jrhelgesonConnect With a Mentor Commented:
Does DNS do a WINS lookup to resolve addresses?  (IT's a setting within DNS server).

It really does sound like it could also potentially be a WINS issue.  Check replication and check the integrity of the WINS database.
Looks like you're having AD replication issues and your users are authenticating against a domain controller that isn't recognized as trusted by the filer.  This is very common... that is to say I see this kind of stuff frequently.

First step - on the users machine, from the command prompt, run "KLIST" to get the list of certificates the user/computer holds, and also run "echo %logonserver%" to get the name of the server that they logged into.

Gathering those two bits of information you'll start to see patterns.   One server is likely not generating Kerberos tickets that match the encryption/signing requirements of the NAS/filer.  The second error indicates that it doesn't recognize the user credentials/Kerberos ticket at all.  That is where you'll want to check the tickets, and the logon server.

Go to the logon server (domain controller) and verify that replication is taking place. Run the following commands from an elevated command prompt.
repadmin /syncall /Aedq
repadmin /syncall /AePdq

Ensure that all FSMO roles are held by an existing server.

I don't want to go into detail on AD repair until we are certain this is the issue.
olaf_joerkAuthor Commented:
Thanks for your reply. I tested with two clients (I had access to) and the Logonserver was the right one. Klist gave me a list of cached certificates. But I don't know what to do with them.

At the domain controllers I checked replication and all was well. The FSMO roles point to our first domain controller. So far I can't see a problem.

BTW, I still entertain suspicion that the problem is name resolution related. But I haven't found anything concrete.
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

I hope you kept a list of the certificates, and I trust the machines were having problems at that time?

Within the list of certs, what did the Kerberos ticket look like for that CIFS Share on the filer?  e.g.
#4>     Client: jrhelgeson @ FOO.LOCAL
        Server: cifs/NETApp.FOO.local @ FOO.LOCAL
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 3/28/2014 8:13:12 (local)
        End Time:   3/28/2014 18:12:15 (local)
        Renew Time: 4/4/2014 8:12:15 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

Open in new window

olaf_joerkAuthor Commented:
At the moment the computer doesn't have problems. The ticket looks like:

#2>   Client: user @ DOMAIN.NAME
        Server: cifs/STORAGE-01 @ DOMAIN.NAME
        KerbTicket (Encryption Type): RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
        Start Time: 3/28/2014 16:25:25 (local)
        End Time:   3/29/2014 2:25:25 (local)
        Renew Time: 4/4/2014 13:31:23 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)

Open in new window

Apart from Ticket Flag and Session Key Type all looks the same. Is the number significant? All tickets had similar entries. Shall I look only to klist output if the computer has problems?
Thanks for your support. Wish you a nice weekend.
The number only signifies the numerical order so you can find it/reference it easier.  No significance outside that.

What is curious is that the ticket only has the device name, not the FQDN (on line 2).  Server: cifs/STORAGE-01 @ DOMAIN.NAME - versus -

Also, the encryption type for the session key - last line, that one is important.

I take it this was on a machine that was working?  You'll need to do this on a machine when it doesn't work to compare.

Also; Are you using WINS in this environment?  It could be that the filer isn't able to see back to the machine because it cannot 'see' it without the FQDN for a DNS lookup.

Ensure that your DHCP server is registering leases with the DNS server, and removes those DNS/PTR records when the lease is expired.  Also ensure that the filer has the FQDN info and is pointing to valid DNS servers.
olaf_joerkAuthor Commented:
Ok, I asked the the staff with problems in the remote location to send me the klist output, if problems occur again. We are using WINS. The DHCP server is registering/removing leases with the DNS server. The filer points to valid DNS servers.

I'll wait for the user output ...
olaf_joerkAuthor Commented:
you pointed into the right direction. It was a WINS- AND DNS-problem. We sorted it out.
We had a broken WINS replication and one of the name servers treated our computers as externals and so it did not give out the internal view. It's all fixed now. Thank you for your support.


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.