Re: Win2003 server/SMB -- SMB signing (different issue than

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Friday, Dec 31, 2004, at 11:12 US/Central, Robert Citek wrote:
> Apparently so.  I tried connecting via smbclient on an FC1 machine 
> (samba-client-3.0.7-2.FC1) and it connects just fine.

> On Sat, 2005-01-01 at 06:54, Robert Citek wrote:
> Spoke a bit too soon.  While smbclient works just fine, smbmount does 
> not:
> $ smbmount ...
> cli_negprot: SMB signing is mandatory and we have disabled it.

Now that's a different issue.  There is both the handshake change and
then the SMB signing requirement.  SMB signing can be majorly _broken_
in pre-NT5.1 (XP/2003) systems, even some elements in NT5.0 (2000).**

Remember, _only_ Linux offers the "smbfs" kernel VFS "hack" that allows
it to use user-space "smbclient" to access SMB mounts.  If you are not
running a "smbfs" kernel module that is compatible with the current
userspace "smbclient," then you'll have issues like this.

In a nutshell, you probably need to rebuild your kernel with the newer
kernel "smbfs" code from Samba 3.  And, again, this is a Linux-only
hack, and not supported by any other UNIX.

Which is why Service for UNIX (SFU) is the best option for native
Windows Servers that will serve UNIX/Linux clients in general.

Always provide the _native_ protocol the _client_ expects.  Because the
server is just pushing out the data, but the client is running programs
and doing RPCs and expects interfaces to be there.  Although Samba
servers have UNIX/Linux extensions that solve most of these, native
Windows servers do not.  Especially not Windows Server 2003.

> 21137: protocol negotiation failed
> SMB connection failed
> I've googled but haven't found any clear answers.  For example, some 
> sites suggest putting in 'client signing = yes' That didn't help.  
> Others suggested I use mount.cifs.  That didn't work either.  
> Apparently, the FC1 kernel I have does not support CIFS by default.  
> Unfortunately, I can't find a module to modprobe, either.

Have you updated your kernel for Fedora Core 1 to 2.4.22-1.2199?
Or Red Hat Linux 9 to 2.4.20-37.9.legacy?

I'm not sure they will include the code.  I don't have a system in front
of me to check.

> Still googling and reading.  Any pointers?

Yes, my first instinct is the kernel "smbfs" v. userspace "smbclient"
difference.  It sounds like the former does not support the features of
the latter.

Try updating _both_ your kernels _and_ your Samba versions on CL3.1
(RHL9) and CL3.2 (FC1) to the _latest_ from FedoraLegacy.ORG.  It might
be a good idea to get the kernel source and inspect the kernel "smbfs"
module compatibility for Samba 2.2/3 with the SMB signing support.

Especially if you're going to have to rebuild anyway.

-- Bryan

**NOTE:
One of the things that Microsoft _does_ is "auto-disable" this
requirement on NT4 and DOS7 (95/98/ME).  I personally love how Microsoft
silently disables security features for compatibility, without a bit of
warning.  The Samba client, on the other hand, will notify you.

As I mentioned before, don't confuse "works" with "works as configured"
-- or expect to be bitten and bitten hard by assumption.  Especially
when you are configuring Windows servers with SMB signing and/or IPSec.
 
I was on a project where we were exchanging SMB signed and IPSec packets
between a few platforms.  When the Windows Server stack got flustered
with traffic, it would _silently_drop_both_ security features.  While
other Windows systems cliently accepted the lack of security, our IBM
AIX client did not, and barked when it no longer received IPSec packets.

Microsoft continually claimed it was an IBM issue.  And they will
_never_ admit this is how, indeed, Windows Servers operate -- even
through NT5.1 (XP/2003).

-- 
Bryan J. Smith                                    b.j.smith@ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.




-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.