Samba smbclient to NetApp (Data ONTAP) Filer SPNEGO/NTLMSSP token negotiation problem

[Fred Zellinger]

Hello,

I am posting an answer to a question I asked of this list several days
ago.  I am trying to include enough keywords describing my problem in
the hopes that anyone having the same problem will find this and save
themselves weeks of debugging effort.

I am using linux samba smbclient and/or linux-cifs mount.cifs to
connect to a NetApp filer.  AFAIK my problems have nothing to do with
Samba version (within the 3.X series) or NetApp filer version (within
the 7.X series).

Our network uses Microsoft Active Directory for authentication.  For
the purposes of the examples below, my AD username is my_username, my
AD domain is my_domain.my_company.com.  The server 'the_server'
happened to be in some other domain 'other_domain', but that appears
to be irrelevent.

When I try a simple 'smbclient' command:

smbclient -U my_domain.my_company.com/my_username%mypassword
//the_server/some_share

I get an error message:

session setup failed: NT_STATUS_MORE_PROCESSING_REQUIRED
did you forget to run kinit?

If I increase the debugging level of smbclient (-d 10), I get some
other interesting messages towards the end:

spnego_parse_auth_response failed at 1
Failed to parse auth response
SPNEGO login failed: Invalid parameter


At this point, any sane person would run off investigating kerberos
authentication and SPNEGO, then start fiddling with NTLMv2 vs NTLMv1
and SMB signed versus unsigned authentication tokens.  Also, this
person would try all possible combinations of command line options to
smbclient, trying to explicitly specify IP addresses and different
workgroups/domains, combinations of upper/lower case spellings and
perhaps dig into strange character sets.

Also, there would be some MicroSoft fileserver nearby, and smbclient
would work with it JUST FINE(!!!) with nearly all permutations of
smbclient commands.

Next, you would contact NetApp support.  They would claim CIFS
compliance and tell you to use a CIFS client.  So, you research
linux-cifs and the mount.cifs command.  linux-cifs is integrated into
the linux kernel, but its codebase and capabilities aren't really
different from Samba...they are effectively siblings....debugging
mount.cifs is just a lot harder.

Next, you might get your local NetApp filer admin to turn on debugging
on the server.  The server admin would tell you they were seeing
messages like this:

auth.trace.spnegoAuthentication.statusMsg:info]: AUTH: SPNEGO- Could
not unpack NTLMSSP Authenticate token

The fact that NTLMSSP authentication tokens weren't being parsed
properly would lead you to believe that there must be something wrong
with how Samba<->NetApp perceive certain authentication mechanisms
should be implemented.  Obviously either Samba or NetApp isn't
following some (undocumented) standard.

Here you will remain for the next few weeks, pouring over network
traces pulling out your hair and cursing anyone with the word
'support' in their job title for their ineptitude.

Alas, you may be lucky enough to try running smbclient this way:

smbclient -U my_domain/my_username%mypassword //the_server/some_share

The mere removal of my_company.com from the 'domain' specification
will cause NetApp to cooperate at all levels.  Even mount.cifs will
work just fine.

Apparently, the NetApp filer doesn't like the 'extended' full domain
my_domain.my_company.com, and will only parse the short my_domain
properly.  This is OK, but during the debugging process where you
tried to connect to a Microsoft fileserver and
my_domain.my_company.com worked just fine, you believed that NetApp
should accept the extended domain too.

Also, you may have been lucky enough to have someone in support to
point you to NetApp's bugs 50610 and 57032:
http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=50610
http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=57032

Of course, you need a now.netapp.com account to see those bugs, and
unless you have one because you bought some NetApp products or someone
lent you their account, you cannot see that.  Those bug reports apply
to the MSWindows 'net use' command, and unless you were really smart
(I am not), you wouldn't realize exactly how they applied to the Linux
SAMBA smbclient command.  (And, NetApp support would not have found
this bug easily either, because it is filed under Microsoft
networking, and you are using Linux Samba).

So, I hope that this post is found by people who need it out on the
internet, and the world becomes a better place.